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 Sat, 29 May 2004 22:59:46 GMT

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

I was certainly a bit too harsh on HttpClient. I just feel very bitter
for having spent over two years of my life trying to bend the
limitations of the 2.0 API in all sorts of creative ways instead of just
doing things right

I just wish that certain design decision were not made the ways they had
been made. If not for just one but fatal design mistake (which is that
monstrous HttpMethod interface) we would not need a complete rewrite in
order to be able to fix known design limitations

Actually I myself have a mission critical system with 250,000 users that
makes a heavy use of HttpClient 2.0rc2 and I am not losing my sleep at
night. HttpClient 2.0 has been serving well in many, many other
applications, as our users have been telling us. Since the final 2.0
release (mid February to date) we have not have a single serious bug
report. HttpClient 2.0 may not be pretty but it proved quite reliable

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

By the time HttpClient 3.0 goes BETA we will certainly revisit this

Obviously you command a pretty good knowledge of HttpClient 2.0
internals. If you had a look at 3.0aplha1 and let us know whether you
see it as improvement compared to 2.0, it would be greatly appreciated


> > 
> > (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,
>   Attila.
> > 
> > Oleg
> > 
> > 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message