IBM Support sometimes queues work for customers and provides test or debugging fixes. A common location for the fixes is in the install_root/classes directory.

By default, the install_root/classes directory is picked up first in the WAS class path to let it override other classes.

Putting a fix in the directory lets you verify that the fix does indeed solve your problem. After verifying that the fix solves the problem, you are supposed to delete the fix from the install_root/classes directory to return the system to a working state.

If you do not remove such fixes from the install_root/classes directory, one can experience errors.

• Report the stdout and stderr logs to the console window, by adding the -is:javaconsole parameter to the install command:

  • install -is:javaconsole
    

    Capture the stream to a file with the following commands

    install -is:javaconsole > captureFileName.txt 2>&1
    

  • install.exe -is:javaconsole
    

    Capture the stream to a file with the following commands

    install -is:javaconsole > drive:\captureFileName.txt
    

• Capture additional information to a log of your choice with the -is:log file_name option.

• Turn on additional installation logging by passing the -W Setup.product.install.logAllEvents="true" parameter to the install command:

  • install -W Setup.product.install.logAllEvents="true"
    

  • install -W Setup.product.install.logAllEvents="true"
    

If no Java process exists or if the message does not appear, examine the same logs for any miscellaneous errors. Correct any errors and retry.

You can find the SystemOut.log and SystemErr.log files in the following platform-specific directory:

• install_root/profiles/profile/logs/servername

• install_root\profiles\profile\logs\servername

To stop server1 from the command line:

• install_root/profiles/profile/bin/stopServer.sh server1

• install_root\profiles\profile\bin\stopServer server1

If you enable security, specify the -user and the -password parameters of the command.

To start the deployment manager from the command line:

• install_root/profiles/profile/bin/startManager.sh

• install_root\profiles\profile\bin\startManager

Press Ctrl+Alt+Delete and type T to open the Task Manager. Click the Processes tab and the Image Name column header to sort by image name. Look for processes named java.exe.

Open a command window and issue the top command to see a display of running processes. If the top command is not available on your UNIX system, use the ps command

ps -ef | grep java

If no Java process exists or if the message does not appear, examine the same logs for any miscellaneous errors. Correct any errors and try again to start the deployment manager.

Test your environment by starting your Application Server, your Web server, and using the snoop servlet with an IP address.

1. Start the Application Server. In a Network Deployment environment, the Snoop servlet is available in the cell only if you included the DefaultApplication when adding the Application Server to the cell. The -includeapps option for the addNode command migrates the DefaultApplication to the cell. If the application is not present, skip this step.

   Change directories to the install_root/profiles/profile/bin directory and run the startServer command:

   • ./startServer.sh server1

   • startServer server1

2. Start the IBM HTTP Server or the Web server that you are using.

   Use a command window to change the directory to the IBM HTTP Server installed image, or to the installed image of your Web server. Issue the appropriate command to start the Web server, such as these commands for IBM HTTP Server:

   To start the IBM HTTP Server from the command line:

   Access the apache and apachectl commands in the IBMHttpServer/bin directory.

   • ./apachectl start

   • apache

3. Point your browser to http://localhost:9080/snoop to test the internal HTTP transport provided by the Application Server. Point your browser to http://Host_name_of_Web_server_machine/snoop to test the Web server plug-in.

   The HTTP Transport port is 9080 by default and must be unique for every profile. The port is associated with a virtual host named default_host, which is configured to host the installed DefaultApplication and any installed Samples. The snoop servlet is part of the DefaultApplication. Change the port to match your actual HTTP Transport port.

4. Verify that snoop is running.

   Either Web address should display the Snoop Servlet - Request/Client Information page.

5. Remote IBM HTTP Server only: Verify that the automatic propagation function can work on a remote IBM HTTP Server by using the following steps. This procedure is not necessary for local Web servers.

   1. Create a user=adminUser, password=adminPassword in the IHS_install_root /conf/admin.passwd file. For example: c:\ws\ihs60\bin\htpasswd -cb c:\ws\ihs60\conf\admin.passwd adminUser adminPassword

   2. Use the administrative console of the deployment manager or the Application Server to enter the User ID and password information that you created for the administrative user of IBM HTTP Server. Go to Servers > Web server > Web_server_definition > Remote Web server administration. Set the following values: admin Port=8008, User Id=adminUser, Password=adminPassword.

   3. Set the correct read/write permissions for the httpd.conf file and the plugin-cfg.xml file. See the IHS_install_root /logs/admin_error.log file for more information.

   Automatic propagation of the plug-in configuration file requires the IBM HTTP administrative server to be up and running. If you are managing an IBM HTTP Server using the WAS administrative console, the following error might display

   "Could not connect to IHS Administration server error"
   

   Perform the following procedure to correct the error:

   1. Verify that the IBM HTTP Server administration server is running.

   2. Verify that the Web server host name and the port that is defined in the WebSphere Application Server administrative console matches the IBM HTTP Server administration host name and port.

   3. Verify that the fire wall is not preventing you from accessing the IBM HTTP Server administration server from the WAS administrative console.

   4. Verify that the user ID and password that is specified in the WAS administrative console under remote managed, is created in the admin.passwd file, using the htpasswd command.

   5. If you are trying to connect securely, verify that you export the IBM HTTP Server administration server keydb personal certificate into the WAS key database as a signer certificate. This key database is specified by the com.ibm.ssl.trustStore directive in the sas.client.props file in the profile where your administrative console is running. This consideration is primarily for self-signed certificates.

   6. If you still have problems, check the IBM HTTP Server admin_error.log file and the WAS logs (trace.log file) to determine the cause of the problem.

1. Start the Application Server.

2. Point your browser to http://localhost:9060/ibm/console.

   The HTTP Admin port is 9060 by default and must be unique for the administrative console of each stand-alone Application Server. The port is associated with a virtual host named admin_host, which is configured to host the administrative console, which is installed by default as a system application. Change the port to match your actual HTTP Admin port.

   If you have problems accessing the administrative console after installation, check the installAdminConsole.log file for a failure indication. Clean up the system temporary directory and reinstall the administrative console using the wsadmin scripting facility.

3. Type any ID and click OK at the administrative console window.

The server starts. The administrative console starts. We can access the administrative console through the browser. The administrative console accepts your login.

• Deployment manager administrative console method:

  Click System administration > Nodes > Add Node and follow the wizard. The default SOAP port for the Application Server is 8880. Use localhost as the value of the Host name field, if the Application Server is on the same machine.

• Command-line method assuming the SOAP port of the dmgr is 8879:

  • install_root/profiles/profile/bin/addNode.sh localhost 8879 -includeapps

  • install_root\profiles\profile\bin\addNode.bat localhost 8879 -includeapps

If you enable security, specify the -user and the -password parameters of the command.

Tool information is being logged in file
           C:\Program Files\IBM\WebSphere\AppServer\profiles\Profile01\logs\addNode.log
Begin federation of node AppServer01 with Deployment Manager at
           localhost:8879.
Successfully connected to Deployment Manager Server: localhost:8879
Servers found in configuration:
Server name: server1
Stopping all server processes for node AppServer01
Creating node agent configuration for node: AppServer01
Reading configuration for node agent process: nodeagent
Adding node AppServer01 configuration to cell: AdvancedDeploymentCell
Performing configuration synchronization between node and cell.
Launching node agent process for node: AppServer01
Node agent launched. Waiting for initialization status.
Node agent initialization completed successfully. Process ID is: 3012
Node AppServer01 has been successfully federated.

By default, the Java 2 SDK caches the IP address for the domain name service (DNS) naming lookup. After resolving the host name successfully, the IP address stays in the cache. By default, the cache entry remains forever.

This default IP caching mechanism can cause problems, as described in the following problem scenarios.

Problem scenario 1

Suppose the Application Server at host1.ibm.com has an initial IP address of 1.2.3.4. When a client at host2.ibm.com conducts a DNS lookup of host1.ibm.com, the client stores the 1.2.3.4 address in the cache. Subsequent DNS name lookups return the cached value, 1.2.3.4.

The cached value is not a problem until the host1.ibm.com IP address changes, to 5.6.7.8, for example. The client at host2.ibm.com does not retrieve the current IP address, but always retrieves the previous address from the cache.

If this scenario occurs, the client cannot reach host1.ibm.com unless you stop and restart the client process.

Problem scenario 2

Suppose the Application Server at host1.ibm.com has an initial IP address of 1.2.4.5. Although the IP address of the application server does not change, a network outage can record an exception code as the IP address in the cache, where it remains until the client is restarted on a working network.

For example, if the client at host2.ibm.com disconnects from the network because of an unplugged cable, the disconnected lookup of the Application Server at host1.ibm.com fails. The failure causes the IBM Developer Kit to put the special exception code entry into the IP address cache.

Subsequent DNS name lookups return the exception code, which is java.net.UnknownHostException.

IP address caching and WebSphere Application Server process discovery

If you change the IP address of a federated WAS node, processes running in other nodes cannot contact the changed node until you stop and restart them.

If a deployment manager process starts on a disconnected node, it cannot communicate with cell member processes until you stop and restart the deployment manager process. For example, plugging in an unplugged network cable does not restore proper addresses in the IP cache until the deployment manager process is restarted.

Using the IP address cache setting

We can always stop and restart a deployment manager process to refresh its IP address cache. However, this process might be expensive or inappropriate.

The networkaddress.cache.ttl (public, JDK1.4) and sun.net.inetaddr.ttl (private, JDK1.3) parameters control IP caching. The value is an integer that specifies the number of seconds to cache IP addresses. The default value, -1, specifies to cache forever. A value of zero (0) is a specification to never cache.

Using a zero (0) value is not recommended for normal operation. If you do not anticipate network outages or changes in IP addresses, use the cache forever setting. The never caching setting introduces the potential for DNS spoofing attacks.

For more information about the Java 2 SDK

The Java 2 SDK, Standard Edition 1.4 Web site at http://java.sun.com/j2se/1.4/docs/guide/net/properties.html describes the private sun.net.inetaddr.ttl property, which works in both Java 2 SDK, Standard Edition 1.3 (WebSphere Application Server V5.0.0, V5.0.1, and V5.0.2) and Java 2 SDK, Standard Edition 1.4 (WebSphere Application Server V5.1 and V6).

Result

This procedure results in using some simple procedures to debug errors that might be occurring in the installation.

What to do next

The Troubleshooting installation problems contains more detailed debugging and reporting instructions. See Installation component troubleshooting tips for more information about troubleshooting the installation.

For current information available from IBM Support on known problems and their resolution, see the IBM Support page.

IBM Support has documents that can save you time gathering the information that we need to resolve a problem. Before opening a PMR, see the IBM Support page.

See also