![]() |
![]() |
|
Troubleshooting Common Problems
This topic contains the following sections:
If you experience cluster-related problems with WebLogic Server, try applying the latest service pack for your release before contacting BEA Technical Support. The latest service packs may address cluster-related problems. This is especially true for problems related to cluster deadlocking scenarios in early versions of WebLogic Server 4.5 and 5.1.
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, 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 -ms64m -mx64m -verbosegc -classpath $CLASSPATH
-Dweblogic.domain=mydomain -Dweblogic.Name=clusterServer1
-Djava.security.policy==/bea/weblogic600/lib/weblogic.policy
-Dweblogic.admin.host=192.168.0.101:7001 -Dweblogic.management.username=system
-Dweblogic.management.password=systemPassword 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 when providing 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 e-mail.
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 Connection Timeouts
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 operating system documentation for help in correcting this error.
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|