If you are having problems using a Web server plug-in, try these steps:
- Review the file plugin_install_root/logs/web_server_name/http_plugin.log for
clues. Look up any error or warning messages in the message table.
- Review your Web server's error and access logs to see if the Web server
is having a problem:
- IBM HTTP Server and Apache: access.log and error.log.
- Domino Web server: httpd-log and httpd-error.
- Sun Java System: access and error.
- Microsoft IIS: timedatestamp.log.
If these files don't reveal the cause of the problem, follow these additional
steps.
Plug-in Problem Determination Steps
The plug-in
provides very readable tracing which can be beneficial in helping to figure
out the problem. By setting the
LogLevel attribute in the
config/plugin-cfg.xml file
to
Trace, you can follow the request processing to see what is going
wrong. At a high level:
- 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, HTTP or HTTPS.
- It sends the request.
- It reads the response.
- It writes it back to the client.
You can see this very clearly by reading through the trace for
a single request:
- The first step is to determine if the plug-in has successfully loaded
into the Web server.
- Check to make sure thehttp_plugin.log has been created.
- If it has, look in it to see if any error messages indicate some sort
of failure that took place during plug-in initialization. If no errors are
found look for the following stanza, which indicates that the plug-in started
normally. Ensure 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: --------------------------------------------
- Some common errors are:
- lib_security: loadSecurityLibrary: Failed to load gsk library
- The GSKit did not get installed or the installation is corrupt. If the
GSKit did not get installed you can determine this by searching for the file gsk7ssl.dll on
all drives for Win32 or see if there are any libgsk7*.so files in /usr/lib on
UNIX. Try reinstalling the plug-in to see if you can get the GSKit to install
in order to fix this.
- 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 thehttp_plugin.log is not created, check the Web server error
log to see if any plug-in related error messages have been logged there that
indicate why the plug-in is failing to load. Typical causes of this can include
failing to correctly configure the plug-in with the Web server environment.
Check the documentation for configuring
the Web server you are trying to use with the Web server plug-in.
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 server is started. View the administrative
console for error messages or look in the JVM logs.
- In the administrative console, select the problem application server
and view its installed applications to verify that they are started.
If none of these steps solves the problem:
For current information available from IBM Support on known problems and
their resolution, see the following topics on the IBM support page:
For current information available from IBM Support on known problems and
their resolution, see the IBM Support page. You should also refer to this page
before opening a PMR because it contains documents that can save you time
gathering information needed to resolve a problem.
You might find the following topics on the IBM support page helpful: