Fixes are available
7.0.0.17: Java SDK 1.6 SR9 FP1 Cumulative Fix for WebSphere Application Server
7.0.0.27: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
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
APAR status
Closed as program error.
Error description
Slow performance of wsadmin script on WebSphere Application Server v7.0. wsadmin takes 3+ minutes as compare to WebSphere Application Server v6.1. On WebSphere Application Server 7.0 no javacores were generated, which indicated that the api is not being used in the application to set the tcp_nodelay option. On WebSphere Application Server 6.1 we got a bunch of javacores, and all were generated from the trigger, when the setTcpNoDelay() is invoked. and they had the following stack. ============ 3XMTHREADINFO "main" (TID:0x000000011051E500, sys_thread_t:0x00000001100161B0, state:R, native ID:0x00000000000AB0DF) prio=5 4XESTACKTRACE at java/net/Socket.setTcpNoDelay(Socket.java:889) 4XESTACKTRACE at org/apache/soap/util/net/HTTPUtils.buildSocket(Bytecode PC:278) 4XESTACKTRACE at org/apache/soap/util/net/HTTPUtils.post(Bytecode PC:27) 4XESTACKTRACE at org/apache/soap/transport/http/SOAPHTTPConnection.send(Bytecode PC:274) 4XESTACKTRACE at org/apache/soap/rpc/Call.invoke(Bytecode PC:111) 4XESTACKTRACE at com/ibm/ws/management/connector/soap/SOAPConnectorClient$4.run(S OAPConne ctorClient.java:308) 4XESTACKTRACE at com/ibm/ws/security/util/AccessController.doPrivileged(AccessCon troller. java:118) . . . ============ the above stack shows that the follwoing code makes a call to setTcpNoDelay() org/apache/soap/util/net/HTTPUtils.buildSocket This indicates that in WebSphere Application Server 6.1 the SOAP code is setting the tcp_nodelay option, where as this is not done in the WebSphere Application Server 7.0 SOAP code and that is the reason why there is a behavioral difference between WebSphere Application Server 6.1 and WebSphere Application Server 7.0
Local fix
use soap_config.properties file under <WAS_HOME>/properties with option: tcp.no.delay=true and ejb.cache.homes=false soap_config.properties file should contain: tcp.no.delay=true ejb.cache.homes=false
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM WebSphere Application * * Server v7.0 who use SOAP * **************************************************************** * PROBLEM DESCRIPTION: The TCP "no delay" flag may not get * * set in the Apache SOAP code used by * * Application Server, causing * * communication delays. * **************************************************************** * RECOMMENDATION: * **************************************************************** This APAR concerns the Apache SOAP code, spec version 2.3, that is installed in plugins/com.ibm.ws.prereq.soap.jar and is used for Application Server system management functions. A customer noted a significant delay when running a wsadmin script in the AIX environment using WebSphere Application Server 7.0. The same script ran very quickly in version 6.1. It turns out that the SOAP code in com.ibm.ws.prereq.soap.jar attempts to load values from the file soap_config.properties that resides in the same .jar. One of the values in this file sets tcp.no.delay=true. In 6.1 and earlier versions, this setting is loaded correctly. In version 7.0, packaging changes were made that resulted in the SOAP code being unable to find this .properties file. As a result, the tcpNoDelay value does not get set when the Apache SOAP code creates a socket, and may default to false, resulting in a slight delay for every packet sent. Over the course of sending dozens or hundreds of packets, this can result in significant delay.
Problem conclusion
The code was modified to correctly find the soap_config.properties file located in com.ibm.ws.prereq.soap.jar, causing the tcpNoDelay flag to be set to true. The fix for this APAR is currently targeted for inclusion in fix pack 7.0.0.17. Please refer to the Recommended Updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
Temporary fix
Copy the file soap_config.properties (found in plugins/com.ibm.ws.prereq.soap.jar) into $USER_INSTALL_ROOT/properties
Comments
APAR Information
APAR number
PM21239
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
700
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2010-08-25
Closed date
2010-11-18
Last modified date
2011-01-13
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
WEBS APP SERV N
Fixed component ID
5724H8800
Applicable component levels
R700 PSY
UP
Document Information
Modified date:
24 October 2021