![]() |
![]() |
|
Troubleshooting WebLogic Server Clusters
Applying Service Packs
If you experience cluster-related problems with WebLogic Server versions 4.5 or 5.1, try applying the latest service pack for you release before contacting BEA Technical Support. The latest service packs address many of the earlier cluster-related problems with these WebLogic Server versions, especially problems related to cluster deadlocking scenarios.
See WebLogic Server Updates for more information about obtaining and installing WebLogic Server service packs.
Collecting Diagnostic Information
Before contacting BEA Technical Support for help with cluster-related problems, make sure you follow the steps in this section to collect the required diagnostic information for your system. The primary diagnostic information for cluster-related problems is a log file that contains multiple thread dumps (if applicable) from the clustered server. This log file can be helpful in diagnosing a variety of cluster-related problems, but it is especially important for addressing problems related to cluster "freezes" and deadlocks.
Note: If you experience a cluster problem that involves a deadlock between server instances or otherwise causes your cluster to "hang", a log file that contains multiple thread dumps is a prerequisite for diagnosing your problem.
To create the required log file, follow these steps:
% java -ms64 -mx64m -verbosegc -classpath $CLASSPATH -Dweblogic.class.path=./license;./classes;./lib/weblogicaux.jar;./myserver/serverclasses -Dweblogic.home=. -Dweblogic.security.policy=./weblogic.policy weblogic.Server >> logfile.txt
Providing diagnostics to BEA Technical Support
After you have created a diagnostic log file (with thread dumps, if applicable), use the following guidelines to provide the information to your BEA Technical Support representative:
% tar czf logfile.tar logfile.txt
Note: Always include the compressed log file as an attachment to the message. Do not cut and paste the log file into the body of the email.
Addressing Common Problems
The following sections provide solutions to common cluster-related problems. They also provide information for how to diagnose non-specific problems, such as poor cluster performance.
Tuning client connection timeouts with TIME_WAIT
Version 4.5 and 5.1 WebLogic proxy plug-ins do not use connection pooling to access clusters in the presentation tier. If you use a two-tier cluster, each request that a proxy plug-in makes to the servlet/JSP cluster opens an IP socket. After the client closes the socket, the socket remains open on the WebLogic Server for the configured timeout period.
On most systems, the default timeout period is too long to support the numerous, brief socket connections used by clients of a web application. If you have a large number of users accessing your cluster via a proxy plug-in, you may find that the system frequently has a large number of open (but inactive) sockets waiting to timeout.
The timeout period for sockets is determined by the IP implementation of your operating system. There are no WebLogic Server-specific configuration parameters that affect socket timeouts. To reduce the length of time that inactive client sockets remain opened, reduce the IP timeout value for the operating system that hosts the WebLogic Server cluster. The applicable configuration parameters are:
Server fails to join a cluster
There are several reasons why a WebLogic Server does not join a cluster on startup, including general network availability and WebLogic-specific configuration problems. Use this checklist to check your configuration and startup process.
Other items which require troubleshooting include general configuration errors and communications errors, such as:
Note that each operating system has specific configuration requirements for configuring multicast; you should check your OS documentation for help in correcting this error.
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|