tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: svn commit: r582291 - /tomcat/tc6.0.x/trunk/STATUS
Date Fri, 05 Oct 2007 17:48:45 GMT
Remy Maucherat wrote:
> Rainer Jung wrote:
>> So my question is: is there a reliable way to detect, if it would be 
>> safer to just drop a flush request?
> 
> I think flush should still send a flush packet. One scenario would be 
> (in the servlet): write 10 bytes and flush (in this case, the response 
> has not been committed yet). The server should write the response 
> header, then make sure the 10 bytes are sent because it has to send them 
> right away. AFAIK, the front end server will not do that without the 
> explicit flush.

If it's 10 body bytes (thinking about http), then in principle OK, but 
see below.

What if the flush comes before the body and the headers are not yet 
setup for the future body? Then we send out kind of default headers not 
fitting to the response generated afterwards. Of course the flush 
command coming from the webapp is the root of the evil, but in that 
case, doing the flush would not be necessary and harmful.

I looked around in the existing code and found some strange things:

a) the patch we are talking about is for JK and we do something similar 
for http already. This might be a plus point for the patch.

b) the jk code path looks like the sending of the headers resets the 
output buffer, so uncommitted response bytes will be lost 
(JkInputStream.appendHead() first does a outputMsg.reset())

c) For http I've got the impression, that 
Http11Processor.prepareResponse() triggers direct writes via 
InternalOutputBuffer (sendStatus(), write() and sendHeaders()). This 
looks like uncommitted body parts will get out before the headers.

d) in the http case all relevant implementations of doWrite seem to 
implicitely commit the response, if it is not already committed (e.g. in 
InternalOutputBuffer). In InternalOutputBuffer, a flush() also implies a 
commit. Assuming that I'm looking at the right classes, this might fix 
c), but would also let a) for http (i.e. the commit before flush) be 
unnecessary.

e) In the JK case, doWrite() does an implicit commit in
JkInputStream but not in RequestHandler. flush does not do an implicit 
commit in ChannelSocket. Again assuming the classes are correct, the JK 
case indeed needs additional commits to get the headers back early 
enough, but those will destroy the uncommitted content when sending out 
the headers.

As you all know, the class structure is not easy and I might be wrong.

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message