Oleg Kalnichevski commented on HTTPCLIENT-1914:

How many dead routes could one possibly expect? Even if they are in thousands, 
I doubt it would have a considerable impact on the memory footprint of your 

Anyhow, while not super pretty this will allow you clean up whatever idle alive 
connections kept in the pool and also trigger eviction of empty routes from the 
root map. [See this 

static class MyConnectionMAnager extends PoolingHttpClientConnectionManager {

    void cleanup() {
        enumAvailable(entry -> {
            // one might want to do some additional sleanups here


public static void main(String[] args) throws Exception {
    MyConnectionMAnager cm = new MyConnectionMAnager();
    CloseableHttpClient client = HttpClients.custom()

If there is anything else you would like to change in the library code it could 
submit them as a PR at Github.


> MaxPerRoute leak and no possibility to remove a route
> -----------------------------------------------------
>                 Key: HTTPCLIENT-1914
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1914
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient (classic)
>    Affects Versions: 4.5.5
>            Reporter: Corneliu C
>            Priority: Minor
> Hi,
> 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.
> Thanks!

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to