Fusion Application Generic WebLogic HTTP 500: Internal Server Errors
(Doc ID 1372624.1)
Last updated on MAY 01, 2014
Applies to:Oracle Fusion Application Toolkit - Version 220.127.116.11.1 and later
Information in this document applies to any platform.
Web server returns the message "Internal Server Error (HTTP 500)" while working within the Fusion application. What does this mean? Where can I find more details?
This message usually indicates an error on the Web server. This message is too generic to provide the actual cause of the error, but a careful examination of the Web server logs,
can provide clues which may point you in the right direction.
There are a few of things you can infer from an "Internal Server Error" message.
1. The web server is NOT down, i.e it is responding to an HTTP request, since the error is being generated and returned by the web server. Unlike a "Page cannot be displayed"
error which is a default message generated by a browser if it cannot contact the web server. The "Internal server error" message is caused by the web server actually returning an HTTP 500 code.
2. If all users are getting this error, its might indicate a problem with the web server itself, perhaps a lack of system resource, a system-wide failure, or a configuration or
installation issue. If only one user gets the error, its probably just tied to the session of the user, and even may be specific to the current activity
3. The root cause is the web server, and not the application domain or database, even though its possible that an application domain or database response might trigger an error on the web server. For example, SQL returning a large result set might cause an OutOfMemory condition on the web server. If the application domain errors out,
the domain servlet traps it and returns a generic message saying "An error has occurred on the server", it does not return an HTTP 500 error.
The Internal Server Error message is generated by the web server, when the sub-process it called to process the browser's request, did not complete successfully.
The sub-process may be a CGI program, it may be another web server ( Apache proxying to WebLogic), or it may be a servlet ( WebLogic HTTP handing off request to application domain). If the sub-process errors out, or returns an invalid error code, the web server will return an HTTP 500 error code to the browser.
The key therefore in troubleshooting HTTP 500 errors is to find out what sub-process was invoked, and what was the error encountered by the sub-process.
Start by checking the access log on the web server. It will have the URL with the GET or POST request, and the return code.
Here is an example from WebLogic's access.log:
127.0.0.1 - - [27/Aug/2010:18:17:46 -0700] "GET /cgi-bin/test.exe HTTP/1.1" 500 1009
This indicates that a GET was performed with the URI /cgi-bin/test.exe , and it return HTTP code 500 with 1009 bytes in the HTTP response. From the keyword "cgi-bin" its obvious
that this is a CGI program (test.exe) that's being called.
The following line in the access log indicates HTTP 500 code returned when calling a servlet
127.0.0.1 - - [15/Aug/2010:15:37:57 -0700] "POST //?cmd=login&language Cd=ENG HTTP/1.1" 500 1003
Once you have identified the sub-process, note the time of the error, and check the sub-process' output for any messages. Output from CGI errors may be lost and may need special
debugging techniques to capture, but output from servlet errors and proxy-plugins are logged. Output from servlet errors are piped to the web server log and stdout, or to stderr.
On Unix, the stdout and stderr are usually redirected to a file (nohup.out). Since servlets are java programs, unhandled exceptions are printed to the webserver log in the form of a
call stack. The call stack is unique to the kind of exception and can be used to compare with known exceptions.
(See CASE #4 below for an example of a call stack)
Note though, that not all java exceptions translate to HTTP 500 errors, and not all HTTP 500 errors caused by servlets correspond to java errors.
Sometimes a servlet may recover or ignore an exception and manage to return a valid response to the calling web server, mitigating an HTTP 500 code response to the browser.
Some of the common causes of servlet failures are:
- Invalid web server or domain configuration ( these errors should be consistently reproducible)
- Errors from the Application Server that are not captured and translated into a meaningful message for the user.
- Network I/O errors while communicating with Application Server, or to a proxy plugin.
- Out of memory conditions on the web server.
- Problems with the Java runtime.
- System errors, like running out of disk space, insufficient permissions, running out of threads, etc.
- Errors in the servlet code itself. Example: NullPointerException
- Invalid or corrupted Session information, perhaps caused by Proxies, Load Balancers, Timeouts.
- Incorrect web server, JRE, OS patches and or versions.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document