Application Server Solutions for Microsoft IIS and ASP.NET
       solutions   products   partners   company   support   downloads         store
ServletExec Self-Help: FAQ
Back to Search >  Back to Search Results

Faq ID 92
Product ServletExec
Category JSP
Question Declarative Error Handling, Response.sendRedirect(), or JSP error page processing is not working, why?
Answer Readers of this FAQ will usually find that they can easily pinpoint the root cause of the problem by doing this:
  1. save the current java stacktrace they are seeing in ServletExec.log
  2. Increase the response buffer size being used by their servlet or JSP and then reproduce the problem.
  3. compare the newly generated stacktrace to the one saved in step #1 (take note of the line numbers given in both stacktraces... look for differences)
If you find that the new trace gives slightly different line numbers then most likely you just need to follow the new trace to figure out what's going wrong in your code.
If you want further details then please read on:

Read section "JSP.11.3" entitled "Buffering" in the JSP 2.1 Specification. Here is a relevant clip from that section:
The JSP container buffers data (if the jsp directive specifies it using the buffer attribute) as it is sent from the server to the client. Headers are not sent to the client until the first flush method is invoked. Therefore, it is possible to call methods that modify the response header, such as setContentType, sendRedirect, or error methods, up until the flush method is executed and the headers are sent. After that point, these methods become invalid, as per the Servlet specification.

Often, the error seen when this problem occurs is something like:
java.lang.IllegalStateException: reset() failed - data has already been sent to the client.
With SE 5.x and newer, the general symptoms may be described as follows:
You request a JSP page (which names an error handler) and a certain amount of the response is sent to the browser (possibly enough response such that the response looks fine to the naked eye). But before the request can totally complete *all* of its processing something goes wrong in the JSP (or in a JSP that it includes). The something that goes wrong could be a NullPointerException or really any other sort of Exception (basically a typical programming error). At that point the error handling mechanism kicks in... SE attempts to forward to the configured error handler. You can look in the ServletExec.log file and see if the stacktrace includes any mention of handlePageException or perhaps this message (possibly on multiple lines):
   error page could not be sent because some data has already been sent to the client

Basically, once the Headers have been sent to the browser for a particular response, more headers cannot be sent for that same response (a forward or redirect require new/different response headers).
So attempts to perform a forward or a redirect will fail once the response buffer has been flushed. Often the line numbers given in the stacktrace produced under these conditions are not helpful as they don't report the root cause. Note that
<jsp:include page="..." flush="true"/> will flush the response buffer causing the response headers to be sent to the browser. Therefore, attempts to utilize the JSP error page directive within an included (and flushed) JSP will always fail.

Here is information about how to troubleshoot the underlying problem in this situation:

The default size of the response buffer for a Servlet or a JSP is 8k. When it becomes filled, ServletExec will automatically flush it to the client. If necessary, you can increase the size of the buffer by using a page directive [in a JSP] <%@page buffer="2000kb"%> for example... would set the buffer size to 2mb which may or may not be a large enough buffer to allow the natural error handling mechanism to function as expected, or by calling response.setBufferSize() [in a servlet]. This will delay the automatic flushing of the response buffer. For more information about this see section 6.5 of the Servlet 2.2 Specification (2nd paragraph). You should also take a look at the JavaDocs for the forward() method of javax.servlet.RequestDispatcher where it says that is thrown if the response was already committed.
Another way to see what the true, underlying problem was, is to wrap your JSP code in a try-catch block, catching Throwable. Then in the catch block call:
t.printStackTrace(System.out); so that the trace will be written to ServletExec.log.

JSP error page processing performs the following basic tasks:
  • catch any uncaught Exception or Error by catching Throwable
  • forwarding the request to the named error page (which fails in the manner described above if the response has already been flushed)
If you have a JSP that uses a page directive to name an errorPage, look at the Servlet that was generated from the JSP in a plain text editor. There you will see how Throwable is caught and handlePageException() is called which attempts to perform the forward.

Yet another way to possibly learn what the true, underlying problem was is to use a page directive and set the autoFlush attribute to false.

company media information terms of use privacy policy contact us