commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <>
Subject Re: [HttpClient] Clarification of documentation regarding connection release
Date Fri, 28 May 2004 19:59:01 GMT

Your observation is certainly correct. HttpClient#executeMethod should
never leave connection unreleased in case of abnormal termination.
Unfortunately there are several reasons why I personally feel compelled
to leave things as they stand

(1) HttpClient 2.0 API is fundamentally flawed in many ways. For
instance, the entire concept of method recycling is fundamentally wrong.
There's virtually nothing to be gained from recycling method and our
recommendation is NOT use HttpMethod#recycle at all

HttpClient 3.0 (which is now in the early ALPHA state) will address some
of them, but not all. Several of existing design limitations require a
complete rewrite. Basically HttpClient 2.0 is not worth the trouble. I
believe HttpClient 3.0 should already have solved the two problem cases.

(2) Connection leaks can and usually do cause a lot of grief. It's by
far better to be safe than sorry. I am kind of hesitant to change our
recommendation regarding connection release simply because HttpClient
does not feel like a well-behaved library. 

I does not make sense to pretend that HttpClient is a state-of-the-art
stuff because it is not. For the time being, we just want to make sure
that it is useful. HttpClient 4.0 (which is planned to be released as
Jakarta HttpClient) will have a fundamentally different (hopefully
better) architecture and different connection management. We'll do our
best to make sure that HttpClient is not just useful but also feels like
a well-behaved library


On Fri, 2004-05-28 at 19:44, Attila Szegedi wrote:
> Hi all,
> the docs at <> state

> that this is the recommended way of using HttpClient to ensure connections are 
> released:
> try {
>     client.executeMethod(get);
>     ...
>     } finally {
>         get.releaseConnection();
>     }
> Now, this is counterintuitive to me. I'd expect the usage to be:
> client.executeMethod(get);
> try {
>     ...
>     } finally {
>         get.releaseConnection();
>     }
> since it's the contract of all well-behaved libraries I came across to date that 
> methods that exit abruptly (i.e. throw an exception) must not leave any 
> resources allocated. Therefore, it must be safe to call executeMethod() 
> *outside* the try block, since if it exits with an exception, the connection 
> will not be allocated. I took the time to actually go through the source code of 
> HttpClient 2.0, and have found out that:
> - lines 650-678 make sure that the connection object gets 
> released if the connection can't be established. 
> - lines 2663-2696 make sure that the connection is closed if 
> an exception is encountered during sending request/receiving response. 
> These catch blocks have the "doneWithConnection = true" statement that'll in 
> turn cause releasing of the connection object in, 
> lines 1122-1124.
> The only case an already allocated connection object won't get released in a 
> failed call to executeMethod() is in two cases of incorrect usage by the 
> library's client. These are:
> - a HttpMethod object is reused without being recycle()d first, (exception 
> thrown in line 1007).
> - preemptive authentication is used, but the supplied credentials aren't 
> username/password but some other kind of credentials (exception thrown in 
> line 204).
> (Now, you could claim that these conditions are incorrect usage of the library 
> and that you feel no obligation to release the connection under these 
> circumstances, but IMHO you should.)
> Anyway, it'd be good if the documentation at the URL cited above would be 
> changed to indicate that the executeMethod() should be called *outside* the try 
> block - I think it's just the standard rule for all well-behaved libraries that 
> users of the library are expected to release a resource only after the method 
> that allocated the resource completes normally.
> Regards,
>   Attila.

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

View raw message