DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=41772>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41772 Summary: Brand new HttpServletResponse is already committed. Product: Tomcat 5 Version: 5.0.30 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I'm running on Suse 9.3 (I think) with tomcat 5.0.30 running under Java 1.5.0_07-b03. I'm front-ending with Apache 2.2.0 using mod_jk set up to hit an AJP 1.3 connector. As far as I can tell, everything is configured correctly. About 20% of the time, when I hit my application without handing in a session ID, I get an "IllegalStateException: Cannot create a session after the response has been committed". The problem is at its worst when I hit my application using a client OTHER than a web browser. I have tried putting a ServletFilter in front of my application to verify that 1) the session truly cannot be created, and 2) that the response is actually committed before my code touches it. It appears my application is being handed an already commited HttpServletResponse. I have 3 separate applications running in the same tomcat instance. 1) a webservice powered first by Axis, and now by XFire. This bug showed up using both of these libraries. 2) a straight up servlet / JSP webapp powered by struts. 3) a struts-powered app used exclusively for dynamic image generation. In the case of app 1, I ended up hacking XFire to not call response.setBufferSize(), which kept it from triggering an "IllegalStateException: response has already been committed." I don't have any remaining stack traces, as I did this fix several months ago and dumped them, thinking this was the end of the issue. In app #2 everything seems to work fine except occasionally on my login page, where I get this problem occasionally when I hand in no SESSIONID or an expired one. A page refresh usually takes care of it. In app #3, I'm generating images to be included in a dynamically generated PDF. I make a bunch of calls to this app in rapid succession (12-15 images per PDF) and invariably, anywhere between 1 and 5 of them returns a content length of 0. I checked the logs and found this stack trace: (NOTE: that stray line in my SessionFilter class is: ((HttpServletRequest)request).getSession(true); If you need the whole content of that filter, I can send it to you, but that's all it does at the moment.) java.lang.IllegalStateException: Cannot create a session after the response has been committed at org.apache.coyote.tomcat5.CoyoteRequest.doGetSession(CoyoteRequest.java:2270) at org.apache.coyote.tomcat5.CoyoteRequest.getSession(CoyoteRequest.java:2116) at org.apache.coyote.tomcat5.CoyoteRequestFacade.getSession(CoyoteRequestFacade.java:528) at com.mycompany.util.SessionFilter.doFilter(SessionFilter.java:37) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) I would shrug it off as my own bad code, except this occurs before ANY of my code executes, other than the one line in the ServletFilter. I set up an automated test, just to demonstrate the differences in the two requests. It hits the app 50 times in a row (one request at a time) and between 8 and 15 of the requests fail, every time I run it. Here are the headers returned by both a successful and unsuccessful request. Headers for Request 0 (unsuccessful) Date - Tue, 06 Mar 2007 09:38:26 GMT Server - Apache/2.2.0 (Linux/SUSE) Content-Length - 0 Content-Type - image/png Content Length - 0 Headers for Request 3 (successful) Date - Tue, 06 Mar 2007 09:38:30 GMT Server - Apache/2.2.0 (Linux/SUSE) Set-Cookie - JSESSIONID=E4F3D53DD87F132B1668E04A14C2BDC4; Path=/myapp Content-Length - 330 Content-Type - image/png Content Length - 330 I can provide more info if needed. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
