On Mar 1, 2010, at 9:28 AM, Newman, John W wrote:

> 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

John,

The problem your seeing has to do with the buffering of the response.

The Servlet layer typically has some amount of buffering (you can set  
this on JSP page for example, I don't recall the specifics).

For arguments sake, lets say that this buffering amount is 50K bytes.

When you send  a response to the client, the container starts  
buffering the output.

When it reaches, in this case, 50K, it will flush the buffer to the  
client.

At that point, the response is "committed". At any point up to when  
you have reached the buffer size limit, the response is "uncommitted"  
since the system can simply erase the buffer, no harm, no foul.

So what you're seeing is most certainly size related. You may want to  
look at increasing your buffer size, or determine what is being  
written early on in your process.

Regards,

Will Hartung


------------------------------------------------------------------------------
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

Reply via email to