Application Server start or restart problems

Installation program, but an application server does not start, or starts with errors

• Browse the Application Server log files for clues. The log files are located by default in:
  profile_root/logs/server/SystemErr.log and SystemOut.log

  Several applications deployed on an application server or node can take time to start. Browse the SystemOut.log periodically and look at the most recent updates to see if the server is still starting up.

• (UNIX) To watch the progress of the server...
  tail -f profile_root/logs/server/SystemOut.log

• Look for any errors or warnings relating to specific resources with the module, such as web modules, enterprise beans and messaging resources. If found, examine the application server configuration file for the configuration settings of that resource. Then restart the server to see if this component causes the problem.

  (Dist) For example, in a base or non-distributed configuration on Windows systems, browse...

  profile_root/config/cells/Cell/nodes/node/servers/server/server.xml

  ...and examine the XML tags for the properties of that resource. Change its initialState value from START to STOP.

  (iSeries) For example, browse...

  profile_root/config/cells/Cell/nodes/node/servers/server/server.xml

  ...and examine the XML tags for the properties of that resource. Change its initialState value from START to STOP.

• Look up any error or warning messages in the message reference table by clicking the Reference view of the information center navigation and expanding Messages in the navigation tree.

• After creating an application server, synchronize the nodes before saving the configuration settings for the new server. If we do not synchronize the nodes, the new server might not start.

  1. On the Applications server page listing all of the application server, click Preferences.

  2. Select Synchronize changes with Nodes, if it is not already selected.

  3. Click Apply and then click Application servers to return to your list of application servers.

  4. Click Save to save the configuration settings for the new server.

• If the application server is part of a network deployment or multiple server configuration,
  • Verify that you added the application server to the configuration.

  • Verify that the configuration is synchronized between the deployment manager and the node. If auto synchronization is running, wait until the synchronization completes. If we are using manual synchronization, request a synchronization to each node in the cluster.

Before starting an application server

1. Start the deployment manager process...
   • app_server_root/bin/startManager.sh

2. Complete the one-time step of federating the node on which the application server is running to the deployment manager. This step has to be done, even if there is only one node. And even if both processes are on the same physical server.

   1. Verify that the deployment manager is running.

   2. Run the addNode nodename
      cd profile_root/bin
      addNode.sh localhost 8879 -includeapps -startingport 3333

      The deployment manager is using the default SOAP port of 8879. Both processes are on the same machine. All of the installed applications (except the administrative console, which is a system application) on the application server are installed on the deployment manager.

      The startingport parameter avoids a problem with coexisting node agent processes on one machine. All of the ports for the node agent process start at port number 3333. We can also assign ports specifically using the -portprops parameter.

3. Start the node manager process on the nodes hosting the application servers you want to run...
   app_server_root/bin/startNode.sh

4. (iSeries) Use the startNode Qshell script to start the node agent process on the nodes hosting the application servers we are starting.

5. Verify that the logical name specified to appear on the console for the application server does not contain invalid characters like: - / \ : * ? " < > and leading or trailing spaces.

6. If we are unable to start the deployment manager after an otherwise successful installation, look in the profile_root/logs/server/SystemErr.log file and the SystemOut.log file for messages.

7. If we are using Apache Derby and receive an ERROR XSDB6: Another instance of Apache Derby might have already booted the database databaseName error when starting the application server, consult the topic Data access problems for more information.

8. When using a non-root user ID to run application servers, verify that:
   • The non-root user has write access to the app_server_root/temp directory.
   • The JVM has write access to app_server_root/config/plugin-cfg.xml file.
   • The non-root user has access to the logs directory.

9. (iSeries) When using a user profile other than QEJBSVR to run an application server, verify that:
   • The user profile has QEJBSVR specified as its group profile.
   • QEJBSVR is the owner of all files and directories under the profile_root directory. We can use the following command in a Qshell session to set QEJBSVR as the owner:
     chown -R QEJBSVR profile_root

10. The application server might not start in the restricted mode. We can configure an application server to allow or restrict access to internal server classes. The default is to allow access. If access is restricted, the server might not start. If the application server does not start in Restrict mode, change the access to internal classes to Allow.

An error message might appear in the SystemOut.log after restarting an application server

The following error message might appear in the SystemOut.log after restarting an application server:

The socket bind failed for host hostname and port portnumber. The port may already be in use.

This problem might occur if the network is slow, and the port listed in the message text did not finish listening when the application was stopped and restarted.

To verify that this is the problem, check the port status.

To correct this problem, wait for a few minutes after stopping the server:

1. Verify that no ports are listening.
   netstat -a

2. (iSeries) Verify that no ports are listening. Use this CL command:
   NETSTAT *CNN

3. Restart the server

Message "DiscoveryService.sendQuery" exception appears in the FFDC log file

When we start a deployment manager, the deployment manager attempts to discover any configured node agents within its cell. If the deployment agent does not discover the node agents in the cell, it writes an exception to the first failure data capture (FFDC) log file for each node agents that the deployment manager does not discover. If the node agents are not suppose to be running, we can ignore the exception. If the node agents are suppose to be running, the FFDC log file might contain additional information that will help you determine why the deployment manager cannot discover the node agents even though the node agents are suppose to be running.

(iSeries)

The server does not restart on IBM i after applying WAS Version 8.5.0.1

If the server does not restart on IBM i after applying 8.5.0.1, we might receive the following message: "CWWKE0044E: There is no write permission for server directory."

This error occurs only on IBM i when started with OS integration and using the QEJBSVR user.

We can temporarily resolve this by wrapping an invocation of the server command with a script that deletes the contents of the <serverName>/workarea/.sCommandAuth directory.

High Performance Extensible Logging

Troubleshoot administration