|
Problem |
WebSphere Application Server on one machine that has
servlets talking to an ejb in a different appserver on the same machine.
You notice 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 appservers also increase.
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:
Example one:
You notice that when the 15th user tries to connect to the adminserver
via the remote adminconsole, a connection can not be established. This
problem occurs intermittently.
The adminserver by Default has a default MaxOpenConnections = 240, which
is equivalent to 120 physical connections. If you are 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)
Example two:
You try to install a 34 MB WAR file via the adminconsole and the install
times out. The requestTimeout and locateRequestTimeout default setting is
180 (3 minutes). 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 previously mentioned 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, you
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.
Similarly, 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 and start admin
client.
Definitions:
MaxOpenConnections: The cache size in the WebSphere Orb components 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 a new direct IOR. The default
value is 1.
Conclusion:
requestTimeout: This Parameter needs to be changed based on the your
specific requirement. You will need to decide how much time you can spare
each thread waiting on a request message (legacy or local systems).
This setting needs to be tuned based on trial and error in most cases.
Customers prefer to set this value lower than default value. |
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|
|