hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Wade <David.W...@optimation.co.nz>
Subject RE: getMethod.getResponseBody() leaks handles
Date Tue, 12 Aug 2003 01:07:09 GMT

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...


-----Original Message-----
From: Michael Becke [mailto:becke@u.washington.edu] 
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message