Hi Julius, > Ditching releaseConnection() in favour of InputStream.close()??? > +1 +1 +1 !!!
It was before my time, but I think HttpClient used to work that way until sometime around 2.0. Obviously it didn't work well, so the releaseConnection was introduced to plug connection leaks. > By "AutoClose", I guess you mean that it will close itself if the EOF > is read? That makes sense. Yes. AFAIK that already happens in HttpClient 3.x. We just don't tell anybody, so keep it to yourself... ;-) > On this note (things that annoy end-users)... I think > MultiThreadedConnectionManager should become the default connection > manager. If someone really knows what they're doing and doesn't want > MTCM, they will have the ability to turn it off. But if someone > doesn't know what they're doing, MTCM is much better for them. My > personal "numbers" would be "max 30 connections", and "max 30 > connections per host" (not sure if that's how it still works). 30 connections per host can not be the default. RFC 2616 requires that clients open no more than 2 connections per host. There are exceptions for proxies, which are allowed to open 2 connections per host per client. I'm not sure about making TSCCM (which replaces MTHCM) the default. Compared to SCCM (which will replace SHCM) it is a monster, and there's currently two background threads involved. There's plenty of people that follow the tutorial too strictly and keep creating a new HttpClient for each request, or at least one for each thread. Still, defaults are up for discussion. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
