-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David,
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+h2IsACgkQ9CaO5/Lv0PCSjgCgun2oTLTpTXqDu2CgROjOzykA PToAnjLZ/LRs1LpMQGU1PR/UDRHFRzpG =A/Eu -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
