hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject Re: problem with recycling methods - use case
Date Mon, 03 Feb 2003 15:16:26 GMT
Michael Becke wrote:


> I've been looking into this a little more and I'm actually not sure if 
> AutoCloseInputStream should close the stream or not.  I vaguely 
> remember when this was first written and the various interactions are 
> quite complex.  In most cases the AutoCloseInputStream is not wrapping 
> the actual socket stream.  Usually there is another stream in the 
> middle, either a ContentLengthInputStream or ChunkedInputStream.  Both 
> of which do not close the socket stream.  The only case a socket input 
> stream will be closed is when there is no chunking or content length.  
> For this case it is difficult to determine when the response content 
> is complete and therefore when it can be reused.  In this case it 
> might actually be reasonable to close the socket stream and force a 
> reconnect.  What does everyone think?

I spent quite a while crawling over this part of the code, and it seems 
to me that if you don't have a content length or chunked encoding on the 
response, the RFC indicates that the only way for the client to detect 
the end of the content on the response is to actually close the socket. 
 In the case where the "AutoCloseInputStream" wraps the raw socket, the 
raw socket should be closed, because the server is going to close it anyway.

I went over this code carefully to try to insure that calling "close" on 
the getResponseBodyAsStream() result would _always_ be safe.  As a 
result, there is a fairly intricate dance between the stream wrapper, 
the method, and the connection manager, so that they all stay in sync 
with each other, and the appropriate amount of data from a persistent 
connection will be read, rather than attempting to "scan" to find the 
next occurrence of "HTTP/1.1" in the byte stream.


View raw message