|
| Problem |
Problem: WebSphere Application Server on one machine that has servlets
talking to and ejb in a different appserver on the same machine. What he is noticing is the number of threads between the servlets and the ejbs start to increase, the ejb connections to the db increase, and the ORB connections on the appserver that contains the ejb along with the threads between the two apservers increase also.
javacore shows lot of threads are in following state
"Servlet.Engine.Transports:106" (TID:0xFA26D88, sys_thread_t:0x24934A90, state:CW, native ID:0x106C) prio=5
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:429)
at com.ibm.rmi.util.Condition.wait(Condition.java:32)
at com.ibm.CORBA.iiop.IIOPConnection.send(IIOPConnection.java:1501)
at com.ibm.CORBA.iiop.ClientRequestImpl.invoke(ClientRequestImpl.java:510) | | Cause | WebSphere Hangs Webcontainer threads are hanging from one appserver during an EJB call to another appserver. |
| | Solution | Java Orb Properties for Communication/Connectivity Issues . Examples of Adminserver Communication/Connectivity Issues are: . 1) Cust complains that when the 15th user tries to connect to the adminserver via the remote adminconsole, he can not establish a connection. This problem occurs intermittently. . The adminserver by Default has a default MaxOpenConnections = 240, which is equivalent to 120 physical connections. If customer is not able to establish this many connections then the problem seems to be due to the connection cache on the adminServer side. To resolve the connection cache issue, add the following properties into admin.config file to allow adminServer to handle more client connections at the same time. (See below properties after second example) . 2) Cust tries to install a 34MB WAR file via the adminconsole and the install times out. The requestTimeout and locateRequestTimeout default setting is 180 (3 mins), for some situations like the client requesting a large pdf file, or installing a large WAR file in this case, a request will take longer than 180 seconds. Setting the forementioned values to 300 seconds or higher allows for long transactions to complete. To resolve the time out issue add the following properties into admin.config to allow the transaction a longer time to complete. . com.ibm.CORBA.requestRetriesCount=5 com.ibm.CORBA.requestRetriesDelay=3000 // 3 seconds com.ibm.CORBA.requestTimeout=300 // 300 seconds com.ibm.CORBA.locateRequestTimeout=300 // 300 seconds com.ibm.CORBA.MaxOpenConnections=1200 // 1200/2=600 connection . com.ibm.CORBA.ServerSocketQueueDepth=200 . Note: Solaris only has 256 connections per process. In other words, customer can only use com.ibm.CORBA.MaxOpenConnections=256 (256/2=128 physical connections) for his adminServer. Default MaxOpenConnections value is 240 (240/2=120 physical connections). . Save the admin.config and restart the admin server. Simarly, add the following CORBA properties into "java" and "javaw" command lines of the adminclient.bat as follows: . $java -Dcom.ibm.CORBA.requestRetriesCount=5 -Dcom.ibm.CORBA.requestRetriesDelay=3000 -Dcom.ibm.CORBA.requestTimeout=300 -Dcom.ibm.locateRequestTimeout=300 -Xms19m -Xmx128m -Xminf0.1 .......... Do the same thing for $javaw, save adminclient.bat then start admin client. Definitions: MaxOpenConnections: The cache size in the Websphere Orb components to keep track of the IIOP connections. Conceptually, this cache size is unlimited in ORB's point of view, however, the restriction is from the Hardware and JVM. Default value is 240 (equivalent 120 physical connections). . ServerSocketQueueDepth: Increases the JVM socket queue size to hold incoming message/data. The default value is 50. Setting this queue deeper may be required if there are more than 50 clients requesting new connections with a server faster than the server can issue a ServerSocket.accept for those requests. Note that once the connections are established, this queue depth is not relevant any longer. . locateRequestTimeout: Defines the number of seconds to wait before timing out on a LocateRequest message. The default value is 180. . requestTimeout: Defines the number of seconds to wait before timing out on a Request message. The default value is 180. . requestRetriesDelay: The amount of delay time (in milliseconds) between retries. Default is 0. . requestRetriesCount: The number of times we will attempt to send an indirect-IOR request in case a server went down. If this is the case, it will give the LSD an opportunity to give us a new direct IOR. The default value is 1.
Conclusion: requestTimeout:This Parameter needs to be changed based on the Customer specific requirement.Customer need to decide how much time they can spare each thread waiting on a request message(legasy or local systems )
This setting need to be tuned based on trial and error in most of the cases Customers prefer to set this value lower than default value. | |
| | |
| |
|
Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, Object Request Broker (ORB) Operating system(s): Multi-Platform Software version: 3.5, 4.0, 5.0, 5.1, 6.0 Software edition: Edition Independent Reference #: 1178788 IBM Group: Software Group Modified date: 2004-09-06
(C) Copyright IBM Corporation 2000, 2004. All Rights Reserved.
|