What kind of problem are you seeing?
If none of these problem solution descriptions fixes your problem:
- Browse the JVM logs of
the problem deployment manager and application servers:
- Look up any error messages by selecting the Reference view of the
information center navigation and expanding Messages in the navigation
tree.
- Use the Log
Analyzer to browse and analyze the service log (activity.log)
of the deployment manager and any nodes encountering problems. View the activity.log files
in both NetworkDeployment_install_root/logs and ApplicationServer_install_root/logs.
If Java exceptions appear in the log files, try to determine the actual
subcomponent directly involved in the problem by examining the trace stack
and looking for a WebSphere Application Server-related class near the top
of the stack (names beginning with com.ibm.websphere or com.ibm.ws)
that threw the exception. If appropriate, review the steps for troubleshooting
the appropriate subcomponent in the Troubleshooting
by component: what is not working? topic.
For example, if the
exception appears to have been thrown by a class in the com.ibm.websphere.naming package,
review the Naming Services
Component troubleshooting tips topic.
- Ensure that all the machines in your configuration have TCP/IP connectivity
to each other by running the ping command:
- From each physical server to the Deployment Manager
- From the Deployment Manager to each physical server
- Although the problem is happening in a clustered environment, the actual
cause might be only indirectly related, or unrelated, to clustering. Investigate
all relevant possibilities:
- If an enterprise bean on one or more servers is not serving requests,
review the Cannot access
an enterprise bean from a servlet, JSP, stand-alone program, or other client and Cannot access an object hosted
by WebSphere Application Server from a servlet, JSP file, or other client topics.
- If problems seem to appear after enabling security, review the Errors or access problems after enabling security topic.
- If an application server stops responding to requests, or spontaneously
dies (its process closes), review the Web
module or application server dies or hangs topic.
- If SOAP requests are not being served by some or all servers, review the Errors returned to client trying
to send a SOAP request topic.
- If you have problems installing or deploying an application on servers
on one or more nodes, review the Errors or problems deploying, installing, or promoting applications topic.
- If your topology consists of a Windows-based
Deployment Manager with UNIX-based servers, browse any recently-updated .xml and .policy files
on the UNIX-based platform using vi to ensure that Control-M characters
are not present in the files. Edit these files using vi on the UNIX-based
platform, to avoid inserting these characters.
- Check the steps for troubleshooting the Workload Management
component..
- Check to see if the problem is identified and documented by looking at available online support (hints and
tips, technotes, and fixes).
After creating and starting a cluster, the cluster
does not start, and logs show that servers in the cluster are not found
This
error can occur when the configuration is not synchronized from the deployment
manager to a node. If auto synchronization is enabled, wait
until the synchronization has had a chance to run. If you are using manual
synchronization, explicitly request a sync to each node on the cluster.
To
determine whether synchronization has taken place, look at the configuration
on the node machines using the administrative console and verify that the
new cluster members are defined on each node.
One or more nodes do not show up in the administrative
console
This can occur when there is a basic connectivity problem
between the deployment manager server and other servers in the topology. To
determine whether this is the problem, look for the file
serverindex.xml in
the deployment manager directory structure.
- If the problem node does not appear in the list, review the steps for
adding a node to the cluster.
- If the problem node does appear in the list:
- From the deployment manager server, ping the server name as it appears
in the list. If the ping command shows no communication, verify that the host
name is correct in the list, and correct it if necessary, then restart the
deployment manager.
- If the name that appears in the list is the short name, ping the fully
qualified network name. If the corrected name works, update the list and restart
the deployment manager.
- If the problem server uses Dynamic Host Configuration Protocol (DHCP),
try replacing the logical host name with the IP address and restart the deployment
manager. If this resolves the problem, be aware that you must change serverindex.xml each
time the problem server address changes, potentially each time the problem
machine is rebooted. To avoid this problem, consider assigning a static IP
address to the server.
- If you still cannot establish communication between the servers, contact
your network administrator to resolve the problem, and restart the deployment
manager after the problem is corrected.
The addNode command fails
This error
can occur when the deployment manager Domain Name Server (DNS) configuration
is set up improperly. The default installation on Linux uses the loopback
address (127.0.0.1) as the default host address. To verify that this is the
problem, query the host name of the suspect machine. If it returns localhost
127.0.0.1, or if file transfer traces at the node show the node trying to
upload files to a URL that includes 127.0.0.1, the node has an incorrect DNS
configuration.
To correct this problem, update the /etc/hosts file
or the name service configuration file, /etc/nsswitch.conf, to query
the Domain Name Server or Network Information Server (NIS) before searching
hosts.
Application files are not present on all nodes
In
the WebSphere Application Server Network Deployment environment, application
binary files are transferred to the individual nodes where applications are
supported as part of the node sync operation. During node sync, application
files are only propagated if their deployment descriptors specify enableDistribution=true.
This flag is specified as part of the application installation procedure in
the administrative console, and is stored as a property in the install_root/config/cells/cell_name/applications/application_name/deployment.xml file.
To confirm that this is the cause, check
to see whether the enableDistribution flag is set. If it is already set to
true, ensure that the target node is configured to run auto file synchronization.
If
both of these settings are correct and the problem persists, manually perform
an explicit synchronization. If the application files still do not appear
in the installation directory, use the EARExpander tool (located in install_root/bin)
to expand the EAR file from the repository to the installation destination.
On remote nodes, the repository should appear in theconfig/cells/cell_name/applications/application_name.ear/ directory.
After downloading the Network Deployment plug-in
to my system, my server does not start
If you experience this situation,
the most likely cause is that the transport paths in the plug-in must be modified
to work in your environment. See the Example:
Manually editing transport settings in the server.xml file topic for
information on how to modify these settings.
In a clustered environment, a server with debug
mode enabled does not start
This problem occurs when the following
three conditions exist:
- Multiple server processes are configured to run on the same node
- More than one server has Debug Mode enabled
- The debug arguments for more than one of the servers have been left at
the default values, so that more than one server in the node is trying to
use the same debug port (port number 7777).
The server will not start because multiple servers processes running
on the same physical host machine with debug enabled cannot use the same debug
port.
To correct this problem, for each server:
- On the Administrative Console select Server > Application servers > server_name >
Java and Process Management > Process Definition > Java Virtual Machine
- Update the Debug argument so that the address of the debug port (address=port
number) is unique for each server process.