Commons HTTP Client September 19, 2007Posted by Phill in General J2EE, Open Source.
Tags: commons httpclient, multithreadedhttpconnectionmanager
I ran into an issue today with one of our web apps. It connects frequently to a servlet located on another server over HTTP. To do this we were using Commons HttpClient.
There seemed to be a few problems with connections not being closed. I wasn’t sure where the problem was, because we were calling “
method.releaseConnection()” on every call.
Anyway, long story short, it all came down to the connection manager we were using. It was a
MultiThreadedHttpConnectionManager… as my colleague who originally wrote the code has now left, I can only guess as to why. I presume he thought “hmmm, our app is threaded — it should use a multi-threaded connection manager to be on the safe side!” Not a bad decision really. Well, it wouldn’t have been, if the connection manager was an instance variable – unfortunately, a new one was created each time we needed to create an
MultiThreadedHttpConnectionManager uses a connection pool. When you call
releaseConnection(), the underlying connection does not get closed – it just gets put back into the connection pool. So, in effect, what we were doing was creating a new connection pool every single time we needed a connection, and those connections weren’t closed. I think the only reason the problem didn’t occur was due to garbage collection – the connection pools must be set to close down when they’re garbage collected!
Anyway, the moral of this story is: unless you’re actually using the multi-threaded features of the
MultiThreadedHttpConnectionManager, use the