The following topics might help you diagnose problems with
the web server plug-ins.
If you are having problems using a web server plug-in, try these
steps:
- Review the file plugins_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.
Note: If you are using a Veritas File System with large
file support enabled, file sizes up to two terabytes are allowed.
In this case, if you set the LogLevel attribute in the
plugin-cfg.xml file
to LogLevel=Trace, then the http_plugin.log file might grow quickly
and consume all available space on your file system. Therefore, you
should set the value of the LogLevel attribute to ERROR or DEBUG to
prevent high CPU utilization..
At a high level, complete
these steps.
- 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 file 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
- Either GSKit did not get installed or the wrong version of GSKit
got installed. To determine which situation occurred:
On a Windows platform,
search for the file gsk7ssl.dll
On a UNIX platform,
search for a libgsk7*.so files in the /usr/lib directory.
If you cannot find the appropriate file, try reinstalling
the plug-in with the correct GSKit version to see if this fixes the
problem.
- 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
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 that
you are using 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 cannot be pinged, there is no way for
the plug-in to contact them. Possible reasons for this problem include:
- Firewall policies that limit the traffic from the plug-in to the
application server.
- The machines are not on the same network.
- If you are able to ping the machines then the probable cause of
the problem is that the port is not active. The port might not be
active because the application server or cluster is not started or
the application server has gone down for some reason. To verify that
this is the problem, you can try to manually 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 can successfully connect.
- Determine whether other activity on the machines where the servers
are installed is impairing the ability of the server 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 for server status.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Check the administrative
console to ensure that the application servers are started. View
the administrative console for error messages or look in the JVM logs.
Check the administrative console to ensure that the
application servers are started. View the administrative console for
error messages.
- 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:
Change in behavior when the
web server uses an insecure transport
If you have secure
and insecure transports defined, and a secure transport cannot be
obtained due to a system failure, the web server plug-in uses an insecure
transport. This is the default behavior.
This behavior has been
changed in WebSphere Application
Server Version 8.5.5. If a system failure occurs when attempting a
secure connection, and there is an insecure transport, the web server
plug-in does not use that transport. The administrator is made aware
of the problem and can fix it using secure connections.
If you
prefer to revert to the previous default behavior, you can enable
it by setting a custom property on the administrative console. Select
webserver-><webserver_name>->plugin properties->custom
properties, and then set UseInsecure to true.
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: