PK59199: S0C4 ABENDS IN THE CONTROL REGION FROM BBOOXCRT.CPP IN FUNCTION XMEM_EXECUTIONTHREAD::SETUPREQUEST(ACRWOBJ*) | |||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description When using Channel Framework - the Control region may encounter intermittent S0C4 ABENDs in the function XMEM_ExecutionThread::setupRequest(acrwObj*). . This problem does not occur if native HTTP transports are used (which is the default). The problem only surfaces if Channel framework is configured instead. . Based on the type of client, the ABENDs may be quite frequent (we observed about once per day). . As SVCDUMP was generated from the 0C4 ABEND, the Stack trace of the failing TCB is as follows: --------- Offset Function ------ -------- 00000032 XMEM_ExecutionThread::setupRequest(acrwObj*) (4cd7a430, 3326b388, 54f453c0, 1) 000012a2 Java_com_ibm_ws390_orb_XMemCRBridge_queueNativeACRW (32d4c6e8, 54f45580, 54f45584, 54f45588) 00000184 com/ibm/ws390/orb/XMemCRBridge.queueNativeACRW (Ljava/nio/ByteBuffer;Ljava/lang/String;Ljava/ 00000420 com/ibm/xmem/ws390/XMemCRBridge.queueACRW (Ljava/nio/ByteBuffer;Ljava/lang/Object;)V(386 . Java Stack: Method -------- com/ibm/ws390/orb/XMemCRBridge.queueNativeACRW com/ibm/xmem/ws390/XMemCRBridge.queueACRW com/ibm/ws390/orb/XMemCRBridge.queueInboundRequest com/ibm/xmem/channel/ws390/XMemWriteRequestContext.write com/ibm/xmem/channel/ws390/XMemWriteRequestContext.write com/ibm/ws/http/channel/impl/HttpServiceContextImpl.asynchWrite com/ibm/ws/http/channel/impl/ HttpServiceContextImpl.sendFullOutgoing com/ibm/ws/http/channel/outbound/impl/ HttpOutboundServiceContextImpl.finishRequestMessage com/ibm/ws/proxy/channel/http/ HttpProxyServiceContextImpl.finishRequest com/ibm/ws/proxy/channel/http/ HttpProxyConnectionLink.processWork com/ibm/ws/proxy/channel/http/ HttpOutboundConnectionReadyCallback.ready com/ibm/ws/channel/framework/impl/ OutboundVirtualConnectionImpl.ready com/ibm/wsspi/channel/base/OutboundProtocolLink.ready com/ibm/ws/http/channel/outbound/impl/HttpOutboundLink.ready com/ibm/xmem/channel/ws390/XMemConnLink.connectAsynch com/ibm/wsspi/channel/base/OutboundProtocolLink.connectAsynch com/ibm/ws/http/channel/outbound/impl/ HttpOutboundLink.connectAsynch com/ibm/ws/channel/framework/impl/ OutboundVirtualConnectionImpl.connectAsynch com/ibm/ws/proxy/channel/ProxyOutboundConnectionPool.create com/ibm/ws/proxy/channel/http/ HttpProxyConnectionLink.processWork com/ibm/ws/proxy/channel/http/HttpProxyConnectionLink.ready com/ibm/ws/http/channel/inbound/impl/ HttpInboundLink.handleDiscrimination com/ibm/ws/http/channel/inbound/impl/ HttpInboundLink.handleNewInformation com/ibm/ws/http/channel/inbound/impl/HttpInboundLink.ready com/ibm/ws/http/channel/inbound/impl/HttpInboundLink.close com/ibm/ws/proxy/channel/http/HttpProxyConnectionLink.clearLink com/ibm/ws/proxy/channel/http/ HttpProxyConnectionLink.processWork com/ibm/ws/proxy/channel/http/HttpInboundWriteCallback.complete com/ibm/ws/proxy/channel/http/ HttpProxyServiceContextImpl.finishResponse com/ibm/ws/proxy/channel/http/ HttpProxyConnectionLink.processWork com/ibm/ws/proxy/channel/http/ HttpOutboundReadBodyCallback.complete com/ibm/ws/http/channel/impl/ HttpServiceContextImpl.continueRead com/ibm/ws/http/channel/outbound/impl/ HttpOSCBodyReadCallback.complete com/ibm/xmem/channel/ws390/XMemConnLink.callReadCallback com/ibm/xmem/ws390/XMemCRBridge.handleInboundResponse com/ibm/ws390/orb/XMemCRBridge.callReadCallback ---------Local fix Problem summary **************************************************************** * USERS AFFECTED: Users of the HTTP channel in WebSphere * * Application Server V6.0.1 for z/OS where * * clients send pipelined requests to the * * server. * **************************************************************** * PROBLEM DESCRIPTION: An ABEND0C4/ABENDS0C4 is seen in the * * controller region when attempting to * * service the pipe-lined request. * **************************************************************** * RECOMMENDATION: * **************************************************************** After sending the complete response for a request, the HTTP channel gets to a point of starting the persist read for the next request. However, before doing so, it checks whether there is excess data from the last read, which would indicate a pipe lined request. If that data is found, it does not start a read, instead it simply begins parsing the new data. The problem is that the thread handling the response is not in a state where it can handle a new request immediately. The abend is due to that state and the interaction with the servant region.Problem conclusion HTTP channel will now spin off the handling of the new request onto the appropriate thread pool instead of on the current thread. That allows the current thread to exit and clean up the current resources allocated for the request. APAR PK59199 currently targeted for inclusion in Service Level (Fix Pack) 6.0.2.27 of WebSphere Application Server V6.0.1 for z/OS.Temporary fix Test patch sent to handle pipelined requests on new thread, workaround is to not use pipelining.Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: PK65863 Modules/Macros Publications Referenced
|
Document Information |
Current web document: swg1PK59199.html
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server for z/OS
Operating system(s):
Software version: 601
Software edition:
Reference #: PK59199
IBM Group: Software Group
Modified date: May 9, 2008
(C) Copyright IBM Corporation 2000, 2009. All Rights Reserved.