I think we are seeing a similar issue - different use case and symptoms, but same idea, response is sometimes closed and sometimes not.
Can you try it with a very large and small response and see if the size seems to play a role? Because for us, I think a large size is what closes it. Basically, I am getting "cannot forward after response has been committed" sometimes. Our exception handler has a debug mode property, if true, it will take the stack trace and stream it back. In production, this is disabled and it just sends back a rather generic error message. This always works fine. But in debug mode, if the stack trace is quite large (usually is), I'll get "cannot forward after the response committed". It's like it commits the response once the buffer gets past a certain point, but if that isn't reached it doesn't close it until after the entire page is rendered. If I throw a large amount of text in there, the response buffer closes well before the page is even read.. Not sure how related that is, it just struck me as I'm seeing the response close before it should. *sometimes -----Original Message----- From: Mike McNally [mailto:emmecin...@gmail.com] Sent: Sunday, February 28, 2010 8:22 AM To: Stripes Users List Subject: [Stripes-users] When is the HTTP response output stream closed? We're noticing a somewhat weird problem with our Stripes app. Many (most) of our forms are in client-side dialogs. The dialogs aren't complete pages; they're done with various bits of client-side magic. An AJAX request loads a page fragment containing the form, the user types stuff, and upon a button's click the client-side code launches another AJAX request to POST the form. The response to the POST (when successful) is another page fragment, which now will mostly be nothing but a "<script>" block with a snippet of Javascript to close the dialog and trigger reloading of other parts of the page affected by the operation. In other words, if the page is displaying some sort of configuration status, and a dialog provides a way to change something, then upon closing the dialog after a successful update some other portion of the page must be reloaded with the new (changed) configuration stuff. So all that generally works great, except for this one small issue that comes up now and then. Our server-side (Stripes) environment involves a home-grown JPA implementation and a fairly simple database session manager. Basically all that happens is that the session gets initialized early in the Stripes lifecycle, and then after the "ResolutionExecution" stage is done we commit the database transaction and clean stuff up. The strange thing that sometimes happens is this: sometimes, the client-side code that responds to the successful "POST" from one of those AJAX forms manages to start a new HTTP transaction to fetch updated stuff from the server, and that transaction manages to run **before** the code in the previous HTTP request thread has managed to commit the database transaction (the one responsible for the update). To me, what that means is that the HTTP response stream must be completed (closed? that's all I can imagine, but I'm pretty fuzzy on exactly how the high-level Java Servlet APIs relate to the low-level HTTP protocol and the things in particular that the browser sees to convince it that an HTTP response is complete) before the code in our intercept does the "commit." Our intercept is not much more complicated than this: Resolution rv = executionContext.proceed(); boolean closeSession = (executionContext.getLifecycleStage == LifecycleStage.ResolutionExecution) || rv == null; // exception handling, other stuff not really relevant if (closeSession) { session.commit(); } So: is it the case that somewhere inside Stripes - or inside something else - that *after* the JSP code for our page fragment has completed, and before that call to "proceed" returns to our intercept, the HTTP response stream is closed? If so, is there a better place to put our session cleanup code in the lifecycle? One fairly simple thing we've considered is that we could commit the session after the action bean has finished and before we get to the JSP code, leaving it in a "semi-open" state so that page code and utility beans etc. could still access the database read-only. That has the minor problem that forwarding from one action bean to another would become problematic, though that's a pretty rare thing in our application. -- Turtle, turtle, on the ground, Pink and shiny, turn around. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
