This is from a pretty old thread, but I was called away for a bit. > 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.
I know the size of the transmission before it goes on the socket, but not soon enough to put it in the Http header. So, I know the exact number of bytes and read exactly that many. Looking at the EOFSensorInputStream, it looks like it may be helpful for me to call read() one extra time so that the read() on the input stream returns a -1 at some point. Would this be advisable? Or is it ok for me to read just the exact number of bytes I know are there and then close my stream (without read ever returning -1) Mark Mark Claassen Senior Software Engineer Donnell Systems, Inc. 130 South Main Street Leighton Plaza Suite 375 South Bend, IN 46601 E-mail: mailto:[email protected] Voice: (574)232-3784 Fax: (574)232-4014 -----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] Sent: Thursday, May 21, 2015 6:00 AM To: HttpClient User Discussion Subject: Re: Strange SSL error 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
