commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Attila Szegedi <>
Subject Re: [HttpClient] Clarification of documentation regarding connection release
Date Sat, 29 May 2004 21:58:02 GMT
Oleg Kalnichevski <olegk <at>> writes:

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

Gosh, and here we are (my company that is) introducing it into a 
mission-critical production system...

> 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

I can understand that - we're not recycling methods either. The two cases I 
discovered where HttpClient 2.0 can leave a dangling connection upon exception 
(method object reuse w/o recycling and preemptive auth with 
non-username-password credentials) can never occur in our code, fortunately. 
These are actually buggy usages of the library...

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

You got me intrigued. I'll take a look at 3.0. Maybe in 3.0 the developers can 
reach a point of self-confidence sufficient to change the usage recommendation 
in the docs?

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

Well, for me it's a question of self-confidence and professionalism. I mean, I 
know that I'm able to guarantee that any code I write doesn't leak resources on 
exception. Actually, after I analysed the source code of HttpClient I claim that 
authors of HttpClient 2.0 were also up to the task, and spent effort to ensure 
that HttpClient#executeMethod *will not* leak connections - except for the two 
cases of incorrect usage of the library. All it'd take is a single bold step (I 
must admit "bold" here sounds a bit ironic to me as I write it) and update the 
docs :-) Well, if not earlier, maybe in 3.0 you could vouch for the safety of 
that code by updating the docs.

Mind you, I'm all for defensive programming, but I love to have behavioral 
guarantees first, and only be defensive where the guarantees are lacking. Having 
more guarantees from libraries helps keep my code cleaner :-) (i.e. I can't get 
into a situation where I have to explain to a casual reviewer why is (or isn't) 
that statement inside the try block).

> 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

I appreciate that effort. However, 4.0 sounds too remote at the moment :-) We 
have tasks at hand to solve here and for the time being we'll be sticking with 
the 2.0. I just didn't want to have my executeMethod calls within try blocks. 
Hurts aesthetically...

Thanks for your response,

> Oleg

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

View raw message