PM57400: HTTP 202 RESPONSE IS ISSUED WHEN FIRST CHUNK IS QUEUED TO WLM

Fixes are available

APAR status

Closed as program error.

Error description

When a large request is chunked, we issue an HTTP 202 Accepted
response when the first part of the request is queued to WLM.
When the next chunk of data is to be read in it fails because
the client closed the connection after he received the HTTP 202
response.

The symptoms can be messages such as 'Invalid Content length'
and jobs are failing to run because the rest of the request data
is missing.


Here is an example of what could be seen in the trace:

  First chunk of data that was read in is being sent to WLM:

Trace: 2012/01/24 12:50:18.429 01 t=8C36D8 c=UNK key=S2
(13007002)
   ThreadId: 0000002e
   FunctionName:
com.ibm.ws390.channel.xmem.XMemWriteRequestContext
   SourceId: com.ibm.ws390.channel.xmem.XMemWriteRequestContext
   Category: FINEST
   ExtendedMessage: writeCommon; Queueing an HTTP inbound chunk;
more
chunks expected: PooledWsByteBufferImpl: ID: 0 java.nio.DirectB
yteBuffer[pos=0 lim=41067 cap=49152] Owner Count: 1 From pool:
WSByteBufferPool:
com.ibm.ws.buffermgmt.impl.WsByteBufferPool@5e565e5
 6 buffer size: 49152


The server side sends the 202 Accepted response back to the
client:



Trace: 2012/01/24 12:50:18.500 01 t=8C36D8 c=UNK key=S2
(13007003)
   ThreadId: 0000002e
   FunctionName:
com.ibm.ws.tcp.channel.impl.ZAioTCPWriteRequestContextImpl
   SourceId:
com.ibm.ws.tcp.channel.impl.ZAioTCPWriteRequestContextImpl
   Category: FINEST
   ExtendedMessage: writeCommon write buffer[0]: ; [B@3fe73fe7
   RawData:  data_address=00000009f324ffa0, data_length=132

+---------------------------------------------------------------
--------
---+
   |OSet| A=00000009f324ffa0  Length = 0084 |     EBCDIC     |
ASCII
|

+----+-----------------------------------+----------------+-----
--------
---+
   |0000|48545450 2F312E31 20323032
20416363|...&............|HTTP/1.1
202 Acc|
   |0010|65707465 640D0A54 72616E73
6665722D|........./>.....|epted..Transfer-|
   |0020|456E636F 64696E67 3A206368
756E6B65|.>.?..>......>,.|Encoding:
chunke


This causes the client to close the connection. We are going
back for another write on that connection and receive

   ExtendedMessage: write (async); Exception occured, signaling
error on callback object: exception message=Error occurred
during communications processing: EDC5140I Broken pipe.
(errno2=0x0594003D): RV=-1, RC=140, RS=201244320


We go back to read the rest of the data on the TCP connection,
and get a Connection Reset message because that connection has
been reset after we received the broken pipe message.


This only happens when the request is larger than the buffer
size (default is 32k).

Local fix

Increase the buffer size on the following chains:

WCInboundDefault
WCInboundDefaultSecure
HttpQueueInboundDefault
HttpQueueInboundDefaultSecure

The default is 32k.

Problem summary

****************************************************************
* USERS AFFECTED:  All users of IBM WebSphere Application      *
*                  Server V7.0, V8.0, and V8.5                 *
****************************************************************
* PROBLEM DESCRIPTION: WebSphere Application Server Compute    *
*                      Grid for z/OS job dispatches fail when  *
*                      the xJCL associated with the job is     *
*                      large.                                  *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
When Compute Grid job dispatches contain xJCL that is larger
than the chunk size set on the endpoint's channel chain, the
submitted request is sent in chunks.  In this situation, the
application server erroneously sends an HTTP response as soon
as the first chunk is read, causing the connection to be closed
the first chunk is read, causing the connection to be closed
early. The default chunk size is 32K and can be modified via the
maxRequestMessageBodySize Custom Property for the TCP channel
in the affected channel chain.
Note that this problem is specific to Compute Grid job
submissions and does NOT apply generally to chunked HTTP
requests.

Problem conclusion

Code was fixed to send the HTTP response only after all chunks
of the request were read.

APAR PM57400 is currently targeted for inclusion in Fix
Packs 7.0.0.25, 8.0.0.4, and 8.5.0.1 of WebSphere Application
Server.

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
PM57400
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
2012-02-03
Closed date
2012-05-04
Last modified date
2012-11-02

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 UK81738
UP12/10/04 P F210

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.

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SS7K4U","label":"WebSphere Application Server for z\/OS"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
28 October 2021

Tips

PM57400: HTTP 202 RESPONSE IS ISSUED WHEN FIRST CHUNK IS QUEUED TO WLM

Fixes are available

Subscribe

APAR status

Closed as program error.

Error description

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

APAR number

Reported component name

Reported component ID

Reported release

Status

PE

HIPER

Special Attention

Submitted date

Closed date

Last modified date

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

Fixed component ID

Applicable component levels

R700 PSY UK81738

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

Share your feedback

Need support?