One of the Hudson users reported a problem <https://hudson.dev.java.net/issues/show_bug.cgi?id=1838>, which seems like the request/response object leak.
That is, the server is clearly not handling 1000 concurrent requests, yet the ObjectPool class denies the allocation of request, citing the maximum is reached.
The only valid explanation seems to me that the object is leaking.
Looking at ObjectPool, I think the implementation approach is rather prone to memory leak. First, since the request handling thread itself is bound by the limit, this places natural upward bound in the # of request/response object that are concurrently in use, so the value of placing a limit is questionable.
Also, if you do feel it's necessary to put a cap on the pool, you should just make sure that 'unusedRequestPool' doesn't grow beyond certain size. There's no point in keeping track of 'usedRequestPool'.