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:47:34 GMT

Just ran my leaky program with a breakpoint 
in HttpMethodBase.responseBodyConsumed().  I can categorically
tell you it is not called!


-----Original Message-----
From: Michael Becke [mailto:becke@u.washington.edu] 
Sent: Tuesday, 12 August 2003 1:36 p.m.
To: Commons HttpClient Project
Subject: Re: getMethod.getResponseBody() leaks handles

Hi David,

More details below...

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

That's just it, there is no difference.  The call 
setResponseStream(null) has no effect, it is just there to be ultra 
thorough.  HttpMethodBase.responseBodyConsumed() will be called 
immediately after the response body is read.  This will happen if it is 
read from inside or outside HttpMethodBase.  It is based on the socket 

There is no correlation to the socket being lost and reading the 
response.  It is solely because the connection is left open as per the 
HTTP spec 
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1> and that 
a reference to the connection is 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.

The connection is released back to the HttpConnectionManager and it is 
then up to the connection manger to do something with it.  The 
intention is that an instance of HttpClient or HttpConnectionManager 
will be used to execute multiple methods, therefore allowing connection 

> As I originally said and demonstrated I can work around
> this by using getResponseAsStream, or switch OS's but...

The only difference would be if you are calling close() on the stream 
returned from getResponseAsStream() this could in some special 
circumstances close the connection.  As per my previous email you can 
fix this by reusing the HttpClient/HttpConnectionManager, setting the 
header "Connection: close", or by implementing a new type of connection 
manager.  All of these should be easier than switching to a new OS:)


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

View raw message