Troubleshoot: HTTP plug-in component

If you are having problems with the HTTP plug-in component - the component which sends requests from your HTTP server, such as IBM HTTP Server, Apache, Domino, iPlanet, or IIS, to the WebSphere Application Server, perform the following steps:

Review the HTTP plugin log file. It is located at /QIBM/UserData/WebAS51/edition/instance/logs/http_plugin.log Look up any error or warning messages in the message table.
Review your HTTP server error and access logs to see if the HTTP server is having a problem:
- IBM HTTP Server and Apache: access.log and error.log.
- Domino web server: httpd-log and httpd-error.
- iPlanet: access and error.
- IIS: timedatestamp.log.

If the log files do not reveal the cause of the problem, follow the plug-in problem determination steps:

Plug-in Problem Determination Steps

The plug-in provides readable tracing that can be beneficial for problem analysis. Set the LogLevel attribute in the config/plugin-cfg.xml file to Trace. (For the default application server, you can find this file in the /QIBM/UserData/WebAS51/Base/default/config/cells directory.) From there, you can follow the request processing to see what is going wrong. The process is as follows:

The plug-in gets a request.
The plug-in checks the routes defined in the plugin-cfg.xml file.
It finds the server group.
It finds the server.
It picks the transport protocol, usually HTTP.
It sends the request.
It reads the response.
It writes it back to the client.

You can see the process by reading through the trace for a single request:

Determine if the plug-in has successfully loaded into the HTTP server.
- Check to make sure the http_plugin.log file has been created.
- If the http_plugin.log file exists, open the file and check if any error messages indicate some type of failure that took place during plug-in initialization. If no errors are found, check for the following stanza, which indicates that the plug-in started normally. Make sure that the timestamps for the messages correspond to the time you started the Web server:
```
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: ---System Information--- 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: Bld date: Jul  3 2002, 15:35:09 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: Web server: IIS 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: Hostname = SWEETTJ05 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: OS version 4.0, build 1381, 
                                                       'Service Pack 6' 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: ------------------------- 
```
- A common errors is ws_transport: transportInitializeSecurity: Keyring wasn't set. The HTTPS transport defined in the configuration file was prematurely terminated and did not contain the Property definitions for the keyring and stashfile. Check your XML syntax for the line number given in the error messages that follow this one to make sure the Transport element contains definitions for the keyring and stashfiles before it is terminated.
- If the http_plugin.log file is not created, check the Web server error log to see if any plug-in related error messages have been logged that indicate why the plug-in failed to load. Typical causes of this can include failing to correctly configure the plug-in with the Web server environment. See Configure Web server plug-ins for more information.
Determine whether there are network connection problems with the plug-in and the various application servers defined in the configuration. Typically you will see the following message when this is the case:

ws_common: websphereGetStream: Failed to connect to app server, OS err=%d

Where %d is an OS specific error code related to why the connect() call failed. This can happen for a variety of reasons.
- Ping the machines to make sure they are properly connected to the network. If the machines can't be pinged then there is no way the plug-in will be able to contact them. Possible reasons for this include:
  - Firewall policies limiting the traffic from the plug-in to the app server.
  - The machines are not on the same network.
- If you are able to ping the machines then the likely cause of the problem is that the port is not active. This could be because the application server or cluster has not been started or the application server has gone down for some reason. You can test this by hand by trying to telnet into the port that the connect is failing on. If you cannot telnet into the port the application server is not up and that problem needs to be resolved before the plug-in will be able to connect successfully.
Determine whether other activity on the machines where the servers are installed is impairing the server's ability to service a request. Check the processor utilization as measured by the task manager, processor ID, or some other outside tool to see if it:
- Is not what was expected.
- Is erratic rather than a constant.
- Shows that a newly added member of the cluster is not being utilized.
- Shows that a failing member that has been fixed is not being utilized.
Check the administrative console to ensure that the application servers are started. View the administrative console for error messages or look in the JVM log file for more information.
In the administrative console, select the problem application server, and view the installed applications to verify that they are started.

If none of these steps solves the problem:

For specific problems that can cause web pages and their contents not to display, see Troubleshoot: Starting an application.
If you do not see a problem that resembles yours, or if the information provided does not solve your problem, Get support for WebSphere Application Server for iSeries in the Overview topic for more information.

For current information available from IBM Support on known problems and their resolutions, see the following Web sites:

IBM Support has documents that can save you time gathering information needed to resolve this problem. Before you open a problem report, see the following Web sites: