Oleg Kalnichevski <olegk <at> bluewin.ch> 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, Attila. > > Oleg > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
