we try to implement a dynamic re-sizing of a connection pool by decreasing the size of maxPerRoute whenever an error (socket or HTTP level) error occurs; we achieve this by closing the connection as a result of ConnectionReuseStrategy (but now looking to ConnectionBackoffStrategy as a better solution). All this is for failover purposes, basically between Heartbeats (which resets the status of a remote server) any permanent failure should remove the possibility of re-creating connections to same server and eventually leading to failover on a secondary node.
This works fine except for the fact that we cannot go down below maxPerRoute = 1 and there is no possibility to remove an HTTPRoute from the maxPerRoute HashMap (class AbstractConnPool). When last connection is closed (we can assume a permanent failure from the server) the number of available routes is 0, the HTTPRoute is no longer a valid object instance (at least not found in list of getRoutes() from pooling connection manager). However, when a new request is sent for same host then the previous HTTPRoute instance from maxPerRoute HashMap is retrieved with the last value of maxPerRoute.
Beside our particular desire, I see the risk of HTTPRoute's getting into maxPerRoute HashMap with no cleanup ever. If number of routes is high then the map can only increase.
I guess allowing to set maxPerRoute to 0 should result in removal of the reference from the HashMap. Allocation of a new connection is anyway protected by calling getMax() which may return the value of defaultMaxPerRoute.
PS: also it would be great to have HTTPContext in ConnectionBackoffStrategy and/or BackoffManager to be able to decide better if to backOff or probe further.