First of all I cannot reproduce the bug voluntarily. Tomcat 5.5.26 description of a typical case: * The server is up and running. * A servlet is called by a batch running on a mainframe, using a batch browser (Lynx) to call the servlet. * The first thing the servlet does is "((HttpServletRequest)request).getSession()", and the exception is thrown: java.lang.IllegalStateException: Impossible de créer une sessionaprès que la réponse ait été envoyée at org.apache.catalina.connector.Request.doGetSession(Request.java:2221) at org.apache.catalina.connector.Request.getSession(Request.java:2031) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:832) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:843) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:224) at adp.data.RunImportData.doGet(RunImportData.java:68) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:420) at org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:134) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) I searched the forums, read the code of Tomcat, and saw this: for a reason my session is either null or invalidated and something has already started to respond the request. The message contained in the exception corresponds to the resource "coyoteRequest.sessionCreateCommitted". This exception is produced in several servlets not just in a specific one. I have set up a session listener in the configuration so as to free objects related to the session when this one is invalidated.
To get this exception: a) you must request a session b) you must be using cookies for session ID c) the response must already be committed c) is the one I would look at. Are you sure getSession() is the first thing you call? Given you are using the invoker servlet it is likely that the error you are seeing is a side-effect of this. There are lots of reasons for getting rid of the invoker servlet (see http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q2). I suggest removing the invoker servlet and seeing if the error is fixed.
OK I'll get rid of the invoker Servlet, for me it's the best possible explanation why the response should already be committed. One doubt anyway: I've declared a session listener in the tomcat's config so as to be able to trace the creation/removal of sessions (preloading of data / clean up and so on). Do you think a kind of "interference" is possible (if the session listeners are notified asynchronously...) ? well it's just a idea... However I still don't understand the reason why a new session cannot be created if the response has been committed. The session would be reusable for the new calls... and technically speaking I don't get the point. I'll change this next week I hope. Thanks