tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Cruikshank <>
Subject Re: [PATCH] JspWriter "... already been flushed" Error ifpagethrows exception after 8192 bytes
Date Tue, 14 Dec 1999 21:56:28 GMT

>Actually it appears to me that all the implications of forward are
>spelled out in the spec and the implementation is correct.

I didn't mean to imply that jsp:forward or the errorPage are not 
implemented according to spec.  My comments about the whether the 
jsp:forward command should exist were just an offhand comment about the 
spec itself (which, perhaps, is none of my business :)).

The spec does create a rather large obstacle to effective error handling, 
however.  I don't think that throwing an Illegal State Exception and 
obscuring the underlying exception when a Jsp page throws a runtime 
exception can be considered acceptable behavior.  One of the JSP 
programmers that I work with was running into this problem so often, that I 
went ahead and added code to the Jsp pages that catches the Illegal state 
exception, and prints the original exception's stack trace to the screen 
(although I don't think this is an acceptable long term solution).  It may 
be that there is no good solution for the viewers when this happens, but, 
at the very least, the application programmers should somehow have access 
to original page exception in order to work out the bugs that occur when 
the application is in production.  Perhaps it's enough to print a stack 
trace of the exception to stderr.  I don't know.

>Remember that
>the output to the implicit out object is buffered according to the page
>directive buffer attribute, and the autoflush attribute.  The 1.1pr2 spec
>section on jsp:forward says that the IllegalStateExceptoion should be
>thrown if the buffer isn't used and anything has been written to the
>stream that. My reading of it implied that to be the expected behavior
>for a flushed buffer not spelled out in jsp:forward but in the API
>refrence on page 116 as a consequence of clearing a flushed buffer.  Also
>the behavior of error page on p 49 implies that some unspecified failure
>is acceptable for a flushed page. As long as it is buffered and teh
>buffer hasn't been flushed you can forward and handle errorPages fine,
>so what many people do when they need error handling deep in the page is
>to set the buffer to some huge number or turn off autoflushing.

Creating an arbitrarily large buffer is not an option in a high-load 
production environment.  There will always be a page that exceeds the 
limit, anyway. - Alex

>What the above oh-so-clear paragraph says is that I don't see a
>violation ofthe spec in the way the current tomcat handles the code.
>Probobly the part you are looking for is on page 49.
> >>> 12/10/99 05:42PM >>>
>After going through the code some more, I see what you mean.  It's not
>enough to ignore the error in PageContextImpl, because, if someone has set
>up an errorPage, the page will call context.forward() to display the
>errorPage and the RequestDispatcher will (rightly) throw an
>IllegalStateException.  The PageContext.forward throws the
>IllegalStateException, because it can't forward after data has been sent to
>the browser (in the default case, after 8192 characters).
>Unfortunately, this seems to be part of a much larger problem with
>jsp:forward.  The fact that PageContext.forward must throw an
>IllegalStateException if data has been sent to the browser means that it
>can only be safely used before the first character is sent, because the
>number of characters that may be written to the JspWriter without sending
>data to the screen is defined by the users configuration.
>It makes me wonder it Jsp should really have a forward command, even though
>it can be extremely useful.  I can't imagine anyway, aside from creating an
>arbitrarily large buffer, that the forward can be expected to work
>The only fix I can think of for error handling would be to somehow check
>the state of out before trying to clear() and forward().  If data has been
>sent to the client, maybe it should print a benign message and put the
>stack trace  in html comments.  What else can you do?
>- alex
> >That is clearly a bug that needs to be corrected, but I'm afraid your
> >solution is not the right one (see below).
> >
> > > Run the jsp attached file.  If you remove the last "1" in the last
> > > out.print() statement (or any other number) it works as expected.  There
> > > are exactly 8192 numbers that get printed to the writer.
> > >
> > > CAUSE:
> > > When an exception is thrown within a Jsp page, the JspWriter's clear()
> > > method is called before the exception is handled.  The clear() method in
> > > JspWriterImpl checks to see if the "flushed" variable is true, and throws
> > > an exception if it has (I'm not sure why).  [...]
> >
> >Without studying the code, I assume the flushed flag is there to throw
> >exceptions when you try to do things, like clear(), that can not be done
> >once some content has been sent to the client. So resetting it is not the
> >solution. A better solution may be to ignore the exception in the
> >PageContextImpl
> >page exception handling code.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message