tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat 7 Exception initializing page context; Cannot create a session after the response has been committed
Date Thu, 03 May 2012 00:59:55 GMT
Hash: SHA1


On 5/2/12 2:46 PM, David Wall wrote:
> We are running Tomcat 7.0.26 (no httpd front end) with BIO/NIO and
> SSL (entire webapp is in security context) and see this exception 
> periodically on our Linux server:
> May 2, 2012 3:03:45 AM org.apache.jasper.runtime.JspFactoryImpl 
> internalGetPageContext SEVERE: Exception initializing page context 
> java.lang.IllegalStateException: Cannot create a session after the 
> response has been committed

Seems straightforward enough.

> That line of code in our JSP's .java file show it to be method 
> _jspService's second statement:
> pageContext = _jspxFactory.getPageContext(this, request, response, 
> null, true, 8192, true);
> What might cause this?

Producing enough data to cause a buffer-flush to the client, then
trying to create a session (and therefore a JSESSIONID cookie and
associated response header).

> Curious as to why the 'service' method of HttpServlet line 722 is
> called twice in the call stack.

JspServlet is a servlet. Your JSP is compiled into a servlet. One
calls the other. Boom.

> How could any response have been sent out and committed when this 
> seems to be before my JSP's main body of code is even executed?

I too would have expected a forward() or include() in the call stack
somewhere, but something must be generating the content. Or, you have
a tiny tiny response buffer. Or your JSP is flushing the buffer
explicitly or something like that.

> So this is Tomcat throwing an exception before it even reaches my
> code. What might be the cause since of course the webapp works fine
> most of the time.

Unfortunately, this is going to require a bunch of research on your
part to find out what is happening. If you are buffering in a web
server (httpd) or something like that then you may be able to log
state on both sides when these errors occur: httpd can tell you how
many bytes were sent back (or maybe even capture the entire response
if it's small enough) and log it to a file, while your webapp will
obviously be able to catch the exception and log it however you wish.

I would start by catching that exception in a Filter and logging
everything you can about the request and response at that time. Then
wait for it to happen again and see what you can learn. Don't be shy
about dumping absolutely everything to the log when you see that
exception. Just be sure it's the right exception or you might end up
with way too much log output for other mundane exceptions.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message