On Wed, 2015-05-20 at 18:40 +0000, Mark A. Claassen wrote:
> Got it. streamClosed in org.apache.http.impl.execchain.ResponseEntityProxy
> has this :
> // this assumes that closing the stream will
> // consume the remainder of the response body:
> try {
> wrapped.close();
> releaseConnection();
> }
> Wrapped is a ChunkedInputStream
> org.apache.http.impl.io.ChunkedInputStream does this to read the rest of the
> message:
> while (read(buff) >= 0) {
> }
>
> So, when I close the connection, the library makes sure that the connection
> is ready for reuse regardless. And, since the stream is already fully read,
> this does not cause any real activity on the socket.
>
Mark,
Please note that ResponseEntityProxy#eofDetected also triggers
connection release. With chunk coded content the end of stream should be
generated when the closing chunk has been read. It looks like your
application either does not read the closing chunk for some reason or
something is still amiss.
> Events:
> 1) Complete data is read
> 2) [Processing happens here for a length of time]
> 3) InputStream is closed explicitly by the program:
> Closes the HttpConnection
> Reads any unread data (which there is none)
> Resets "updated" to time of close
> Puts connection back in the pool.
> The expiration time will now be calculated using the step 3 time, but the
> server started counting right after step 1
>
> I certainly believe that, in general, step 2 should not take a lot of time.
> (And if it does, maybe make sure the connection is closed first.)
> The only reason I noticed this is because my test case had a sleep(6000)
> right after it read the data. Still, it seems the logic isn't quite correct;
> "updated" should be when the last byte was read, not when it was put back in
> the pool. Whether or not it is worth changing/fixing is a whole different
> question.
>
Generally, as long as the consumer always reads to the end of the
message, the underlying connection should get released at the same time
with the receipt of the last data chunk and the expiry time on the
client side value should be fairly accurate. What can be done though is
that when calculating expiry time the connection manager is to use the
time of the last read operation instead of the time of connection
release. Feel free to raise an enhancement request for that.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
