PQ93181: WEBSPHERE ZOS .3 SECOND DELAY SENDING SOME CHUNKED DATA BACK TO CLIENT.

 A fix is available

Obtain the fix for this APAR



APAR status
Closed as program error.

Error description
In WebSphere zOS V5 some types of data sent as responses to
the client my be sent CHUNKED. Is some instances there may be a
delay during this transfer. We have measured it to be about .3
seconds. This delay is the result of normal TCPIP function, the
sender of the data (WebSphere) may wait for the ACK or
ACKnowledgement from the Client Stack before sending the next
CHUNK. This APAR was opened to consider TCP changes that could
be made on the WebSphere side to prevent the delay.
NOTE: this delay is a wait, no additional CPU or other system
      resources are tied up in the delay.
VERIFICATION STEPS:
    In this case the customer was running the WebSphere V5
  PLUGIN in the zOS HTTP WebServer. We enabled the -vv trace in
  the WebServer and could see this .3sec delay after a HTTP
  write. This Write looks like
08:48:31.535725.: GWAPI:  HTTPD_write()... successful
The following trace message may differ in content but, will show
the .3sec delay. For Example:
08:48:31.535725.: GWAPI:  HTTPD_write()... successful
08:48:31.818681.: APIClassExec return_code=200; HTTP_RESPONSE=20
  0; HTErrorInfo=0; ERRORINFO=0
Also, note that the Transfer-Encoding header looks like:
Transfer-Encoding: chunked
   If the client is going directly to the WebSphere Transport,
this delay still exists, just harder to identify. You may need
to run TCPIP tracing.
Local fix
Set TCPIP NODELAYACK on the TCPIP STACK. Caution should be used
if setting this value. This setting will improve performance
when small amounts of data are being transferred. However, it
could adversely affect transfer of large amounts of data.
Problem summary
****************************************************************
* USERS AFFECTED: All users of WebSphere Application Server    *
*                 V5.0 for z/OS                                *
****************************************************************
* PROBLEM DESCRIPTION: Increase in response time on HTTP       *
*                      requests.                               *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
Delays in sending all the data for an http response can occur
within TCP/IP when the response is sent out from the WebSphere
Application Server in multiple pieces.  Due to the Nagle
algorithm TCP/IP may not send all the response data pieces
immediately.
Problem conclusion
WebSphere Application Server will provide support to disable the
algorithm by setting the TCP_NODELAY socket option on HTTP
connections. The protocol_http_tcp_no_delay and
protocol_https_tcp_no_delay server custom properties will be
activated to allow the ability to control the configuration.
A value of true is the default and will cause the Nagle
algorithm to be disabled via the TCP_NODELAY option.  For a
value of false the server will not disable the Nagle algorithm.

Changes will be made to the V5.0x and V5.1x WebSphere
Application Server for z/OS Information Centers. To access the
latest online documentation, go to the product library page at:

www.ibm.com/software/webservers/appserv/zos_os390/library/

The following descriptions of the protocol_https_tcp_no_delay
protocol_https_tcp_no_delay properties will be added to
"Configuring server properties":

protocol_http_tcp_no_delay

Determines whether or not the setsockopt API is issued to set
the TCP_NODELAY option for HTTP transport connections. A value
of true indicates that the TCP_NODELAY option should be used
for HTTP transport connections. This TCP/IP option disables the
Nagle algorithm for all HTTP transport connections.

Data Type     Boolean

Default       True

protocol_https_tcp_no_delay

Determines whether or not the setsockopt API is issued to set
the TCP_NODELAY option for HTTPS transport connections. A value
of true indicates that the TCP_NODELAY option should be used
for HTTPS transport connections. This TCP/IP option disables the
Nagle algorithm for all HTTPS transport connections.

Data Type     Boolean

Default       True

The table entries for the protocol_http_tcp_no_delay
and protocol_https_tcp_no_delay properties
included in the article "Changing the values of variables
referenced in BBOM0001I  messages" will be updated to indicate
that the value specified for these properties can be changed
in the administrative console by clicking Servers >
Application Servers > server_name > Custom Properties >
New and then adding the property and specifying a different
value. These table entries will also include a link to the
"Configuring server properties" article.

These updated articles will be available in the next refresh of
the V5.0x and V5.1x Information Centers.

APAR PQ93181 is associated with SERVICE LEVEL W502016 of
WebSphere Application Server V5.0 for z/OS.
Temporary fix Comments
APAR information
APAR number PQ93181
Reported component name WEBSPHERE FOR Z
Reported component ID 5655I3500
Reported release 500
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Special Attention NoSpecatt
Submitted date 2004-08-23
Closed date 2004-10-07
Last modified date 2004-11-01

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:
PQ93374

Modules/Macros
BBOUBINF          

Publications Referenced

Fix information
Fixed component name WEBSPHERE FOR Z
Fixed component ID 5655I3500

Applicable component levels
R500 PSY UQ93769    UP04/10/15 P F410

  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


Current web document: swg1PQ93181.html
Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server for z/OS
Operating system(s):
Software version: 500
Software edition:
Reference #: PQ93181
IBM Group: Software Group
Modified date: Nov 1, 2004