On Thu, 2009-04-09 at 16:46 -0700, HockeyDave wrote: > I'm trying to upgrade from Httpclient 3.1 to HttpClient 4.0b2 because I read > that it would be more performant, but I am finding it to be highly > problematic in that it doesn't keep alive connections like 3.1 did.
Well, it just does not. Connection management in HttpClient 4.0 is completely different. > I have > a Servlet application written w/ 3.1 that has rock solid Established > connections. > > After much pain and suffering for a week now, I cannot get HttpClient 4.0b2 > to perform the same way. Connections keep going up and down. Some seem to > stay up for a long time, but others never. > Maybe because they are not supposed to. > I have a need to run like 40 worker threads that use a connection pool to a > remote data center. I need to timeout the worker threads to make sure that > they don't wait too long for a response as I also have a ton of incoming > servlet threads producign new work. In 3.1, I spun up an additional > TimerTask thread to interrupt() the worker thread if the Http connection > took too long. I did this because the setSocketTimeout() expiring would > close the socket and force the connection to re-establish. > > I'm doing the same thing w/ 4.1b2, but am starting to wonder if that's not > the "approved" model to timeout connections w/o losing the keep-alive on > them. Should I be doing this a different way? I want to free up my worker > thread if the http request/response takes too long, but I also want the > socket to stay open. > > Help! I've already lost a week struggling with this. This approach will no longer work with HttpClient 4.0. HTTP connections will always get closed automatically in case of a timeout because the risk of leaving the connection in a inconsistent state is simply too high. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
