Friday 20 April 2012

HTTP 404 Troubleshooting.

Troubleshooting:
Verify that the Web server is responding
Verify that the application server is started
Verify that the application is started
Collect data
If the type of error is not apparent to you or you did not obtain the URL
information, collect the following diagnostic data:

Errors displayed by the user browser, including the URL that failed.

SystemOut log data for the application server

If your application is deployed to a cluster, you might need to collect the logs
from each active server in the cluster

Web server access and error logs

If you are running an IBM HTTP Server, see “IBM HTTP Server, HTTP Server
(powered by Apache) log files
_
Analyze data:

The two key determinations that you can make from the diagnostic data are:
The URL that failed.

Where the failure occurred (Web server, plug-in, application server)
Analyze the diagnostics in the following order:

The browser error display

1.     The page cannot be displayed
2.     JSP error or JSF error
3.     Failed to find resource
4.     File not found
5.     WebGroup/virtual host not defined

The errors displayed by the browser can indicate the failure type and URL that
failed. This might be enough information to resolve the problem.

.SystemOut  Errors

To analyze SystemOut, search for:

1.Web container messages: SRVExxxxE or SRVExxxxW messages
2.JSP messages: JSPGxxxxE or JSPGxxxxW messages
3.JSF messages: JSFGxxxxE or JSFGxxxxW messages
4. Error messages that are related to the application startup


If the failure occurs in the Web container, SystemOut has the most informative
error messages. These might be displayed by the browser also, depending on
the error handling of the application. If no error messages are seen in the
JVM logs, the request most likely did not reach the application server

Web server log

Search for 404 status codes in the access log
A log entry in the NCSA format looks like this:
Remote_host- - date_time "request" status_code bytes
For 404 errors:
1. Search for “404” in status_code.
2 Note the remote_host address, the date_time stamp, and the request URL.
Search for errors in the error log
An error entry in the error log resembles this example:
[date_time] [error] [client Remote_host] error_message
For errors in this entry:
. Search for “error.”
. Correlate the access log entry that you noted with the error log entry by
comparing the date_time and remote_host entries.
3. Note the error_message text
If no other error indications are found, look at the Web server log, which can
tell you the type of error (404 or 500) and the URL that caused the


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The Flow of Request happens from
Load Balancer >> Webserver >> Appserver >> DB

so the investigation for such issues should also follow the same routes .. ( well thats how i follow )

1) Try to check if the url is responding frm your end. ( this will eliminate if its specific to a user or its error for every one)

2) Check the Webserver if its running or not , If its not running start it

3) Check if the application server and application is running .. if not start it


4) Try to access the Aplication directly from the Appserver .. ie using the http transport port. ie wc_defalut .. ( this will identify if the error is due to App server or is with the Webserver/plugin)

5) check for the errors in the Appserver and web server logs

6) Check for the config in the plugin file to ensure that the url which is being hit is avaliable in the plugin-xml.cfg ( If it is not then it could be possible that the plugin was not regeneraed ad propagated after the deployment)

7) Enable the trace in the plugin-xml.cfg to understand in the plugin logs whether the plugin is forwarding the req to the appservers or not .


8) Lastly also check if the page which you are requesting is avaliable within the web modules

If you see one of the following messages, you
might have a problem with the virtual host
configuration:
SRVE0255E: A WebGroup/Virtual Host to handle
url has not been defined. (V6.1)
SRVE0017W: A WebGroup/Virtual Host to handle
url has not been defined. (V6.0)
Error messages with prefixes JSPG, JSFG, or
SRVE have information about the error, including
the URL that caused the problem
  

3 comments:

  1. 1.fisrt i will check access.log file whether the request is reaching to webserver or not
    2.if the request is reaching to webserver u can find an entry with status code,context root and timestamp in access.log file
    3.if url is not correct u will not find dis are all.

    ReplyDelete
  2. 1.fisrt i will check access.log file whether the request is reaching to webserver or not
    2.if the request is reaching to webserver u can find an entry with status code,context root and timestamp in access.log file
    3.if url is not correct u will not find dis are all.

    ReplyDelete
  3. Thanks for the information appreciated been reading for awhile, and just wanted to let you know I continue to enjoy your writing.The best thing is that your blog really informative thanks for your great information! I have got some important suggestions from it..
    digital marketing jobs in hyderabad

    ReplyDelete