Mike, thanks for the detailed reply, but sorry if try one more time to force my point of view ;>
I just don't get why the behaviour should be different. My perspective on this is from a users view of the client and form that perspective it doesn't make sense for the different behaviour and the resulting undocumented side effects when running on MS Sucky Sockets (TM). Yes getResponseBody() reads the whole response using a local buffer. But I can do the same using getResponseAsStream and my code would be almost identical to getResponseBody barring the call to setResponseStream(null); and yet still, in one case a socket connection would be lost. If I take your argument, then it is logical to conclude that getResponseAsStream is incorrectly allowing the socket to be released via releaseConnection and thus not allowing the efficiencies of the keep-alive mechanism. As I originally said and demonstrated I can work around this by using getResponseAsStream, or switch OS's but... Regards David -----Original Message----- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2003 11:54 a.m. To: Commons HttpClient Project Subject: Re: getMethod.getResponseBody() leaks handles Hi David, Please see my responses below. > However, I can see no justification for the difference in behavior > between > getResponseBody and getResponseBodyAsStream -especially as all > getResponseBody does is call getResponseBodyAsStream. The difference > is > caused solely by the line 689 mentioned below and it should be removed. The sole reason for the HttpMethod keeping hold of the connection is so that it can read the response. Once the response has been read the connection is no longer of use. The main difference between getResponseBodyAsStream() and getResponseBody() is that the latter reads the entire response and buffers it. Once that is done the connection is no longer needed and it is released. This is not related to line 689. Please see HttpMethodBase.readResponseBody(HttpConnection) and HttpMethodBase.responseBodyConsumed() for more details regarding connection auto release. Just to note there is no harm is calling HttpMethod.releaseConnection() when the connection has already been released. > Yes I could change to a single instance of the http client, but I > really > don't see why I have to keep an open connection between get method > invocations. If I have finished with the connection and have asked > for it > to be released, then that is what should happen. Please feel free to override the default behavior so suit your needs. By default HttpMethod just releases connections and only forces a close when necessary. This is to support connection keep-alive and help performance where possible. You can force connection close in a number of ways if you like: 1) Call HttpMethod.setRequestHeader("Connection", "close") on all methods before you execute. 2) Implement your own HttpConnectionManager that closes all connections when released. If you take a look at SimpleHttpConnectionManager you will see how trivial this would be if you were so inclined. I hope this helps. Mike --------------------------------------------------------------------- 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]
