|
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. |
|
|
|
|
|
|