I see. ConenctionPool is generic, meant to deal with both server and client http/tcp and other connections. So, it seems to make more sense in this case to NOT change ConnectionPool class at all, but in the DefaultHttpClientConnectionPool.returnConnection() method just skip calling the pool.returnConnection() if fullyOccupied() is true. This would solve the awkward problem of having to pass the second parameter which only really applies to the Client-Http conenctions.  

Actually, looking at this code closely, I think there is a bug in the implementation. If the conenction is fully occupied, that is, it has many outstanding requests, then why would we put it back into the available pool where it will we will try to use it to assign more requests? 

When a waiter is null, it means that there is no more outstanding work for the connection to do, so it should be available again. However, in your code here, when the connection is fully occupied, you leave waiter to be null, so the code puts the connection back into the available list. Is this intended? If so, could you explain why we are doing that?