# Diagnosing problems with WebSPhere requests IBM HTTP Server 6.1 and WebSphere Application Server 6.1 plug-in and later contain new features for solving problems with web server/plug-in/app server requests. For older releases, please refer to [this document](WebSphere.html). Problems occasionally encountered with WebSphere applications include - unresponsive behavior - slow response times - failed requests When WebSphere requests are routed through IBM HTTP Server using the WebSphere plug-in, the same symptoms may have different causes, such as: - problems with authentication modules used within IBM HTTP Server - network problems encountered by WebSphere plug-in when communicating with WebSphere - other issues within IBM HTTP Server which are unrelated to WebSphere Often, the component encountering the failure is determined by increasing the log level in the WebSphere plug-in then checking the plug-in log after reproducing the problem. Understanding and using IBM HTTP Server serviceability features can decrease the need for more plug-in logging and reduce the time required to locate the cause of a problem for requests routed through IBM HTTP Server to WebSphere Application Server. - [Monitoring active requests](#ACTIVE) - [Checking the results of requests which have finished](#LOG) ----- ## Monitoring active requests The [mod\_status](http://publib.boulder.ibm.com/httpserv/manual60/mod/mod_status.html) module provides a view into current web server processing using a web browser. The administrator requests a special URL from the web server to see the internal state. Typically this special URL is protected with some form of authentication or access control ### Preparation A typical configuration follows: ``` # # ExtendedStatus controls whether Apache will generate "full" status # information (ExtendedStatus On) or just basic information (ExtendedStatus # Off) when the "server-status" handler is called. The default is Off. # LoadModule status_module modules/mod_status.so ExtendedStatus On ... # # Allow server status reports generated by mod_status, # with the URL of http://servername/server-status # Change the ".example.com" to match your domain to enable. # SetHandler server-status Order deny,allow Deny from all Allow from .example.com ``` Note the protection for this special page: any client with a client IP address as seen by the web server that resolves to \*anything\*.example.com will be allowed to request the page. Some environments will require a different form of protection, such as entering a user id or password. This URL can be protected using any available protection mechanisms, including LDAP and password files. ### Using the status display The status page is retrieved by loading `http://www.example.com/server-status/?showmodulestate` in the browser. Snapshots of the important part of the report are shown below. #### Viewing an unused thread Look for a value of "\_" for the M field. This request has finished and the thread is unused. ![request finished](status1.jpg) #### Viewing an active mod\_status request Look for a value of "W" for the M field and a value of mod\_status.c for the Module field. ![mod\_status request](status2.jpg) #### Viewing a request being read by the web server Look for a value of "R" for the M field and a value of "..reading.." for the Request field. ![reading](status3.jpg) #### Viewing a request being processed by the WebSphere plug-in Look for a value of "mod\_was\_ap20\_http.c" for the Module field. ![plugin request](status4.jpg) #### Viewing a request where the plug-in is waiting for a response from the application server Look for "mod\_was\_ap20\_http.c" for the Module field and "WR" for the State field. ![plugin waiting for the response](status5.jpg) #### Viewing a request where the plug-in is actively reading a response from the application server Look for "mod\_was\_ap20\_http.c" for the Module field and "RB" for the State field. ![plugin reading the response](status6.jpg) Other values for the State field:
DQ
Plug-in is performing DNS query for the IP address of the server
CN
Plug-in is connecting to the server
SB
Plug-in is sending the request body
WR
Plug-in is waiting for the response line (request has been sent but no response has been sent by the application server)
RB
Plug-in is busy reading and sending the response from the application server
#### Determining how long the request has been active See the SS field for the seconds since the start of the request. ![seconds since the start of the request](status7.jpg) #### Determining which application server has been selected Check the Module Info field. This is only valid for active requests where Module is "mod\_was\_ap20\_http.c". ![plugin backend application server name](status8.jpg) ----- ## Checking the results of requests which have finished The default access log format has been a standard for many years and is assumed by some log scanners. However, if the current log format can be extended without impacting log scanning scripts, additional information is recommended: - information about the module/plug-in handling the request - the name of the application server selected for this request - the response time in microseconds (not shown in examples below) With this information, the adminstrator can often determine where the problem occurs (web server, application server) and whether the problem is specific to a particular application server. ### Preparation Here is a typical access log configuration: ``` LogFormat "%h %l %u %t \"%r\" %>s %b" common ... CustomLog logs/access_log common ... ... CustomLog logs/ssl_access_log common ... ``` Here is the updated configuration, which uses a different log format: ``` LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%h %l %u %t \"%r\" %>s %b %{RH}e %{WAS}e" was ... CustomLog logs/access_log was ... ... CustomLog logs/ssl_access_log was ... ``` The `%{RH}e` field logs information about the module/plug-in which handled the request. The `%{WAS}e` field logs the name of the application server used for the request. The response time in microseconds can be logged by adding `%D` to the format. ### Using the additional access log information #### mod\_status request The WAS field is "-" because this request isn't handled by the WebSphere plug-in. 9.37.242.147 - - [07/Nov/2006:14:21:56 -0500] "GET /server-status/?showmodulestate HTTP/1.1" 200 4668 (mod_status.c/0/handler) - #### Normal 200 response from WebSphere request The handling module is mod\_was\_ap20\_http.c and the WAS field is set to the selected application server. 9.37.242.147 - - [07/Nov/2006:14:19:59 -0500] "GET /servlet/Silly/ HTTP/1.1" 200 418 (mod_was_ap20_http.c/-2/handler) amadeus.rtp.raleigh.ibm.co:9080 #### Client I/O error during WebSphere request The handling module is mod\_was\_ap20\_http.c and the WAS field is set to the selected application server. The plug-in sets the logged HTTP status code to 400 when I/O errors occur communicating with the client. 9.37.242.147 - - [07/Nov/2006:14:21:53 -0500] "GET /servlet/Silly/?fn=output&bytes=200000000 HTTP/1.1" 400 2490368 (mod_was_ap20_http.c/-2/handler) amadeus.rtp.raleigh.ibm.co:9080 #### File not found error for non-WebSphere request The handling module is core.c instead of mod\_was\_ap20\_http.c: 9.37.242.147 - - [07/Nov/2006:14:36:16 -0500] "GET /xxx.html HTTP/1.1" 404 326 (core.c/404/handler) - #### File not found error for WebSphere request The handling module is mod\_was\_ap20\_http.c: 9.37.242.147 - - [07/Nov/2006:14:17:17 -0500] "GET /servlet/Silly/?fn=output&bytes=2000000" 404 59 (mod_was_ap20_http.c/-2/handler) amadeus.rtp.raleigh.ibm.co:9080