[jira] [Commented] (HTTPCLIENT-1914) MaxPerRoute leak and no possibility to remove a route

["Oleg Kalnichevski (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432022#comment-16432022 ] 

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 application.

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 code|https://github.com/apache/httpcomponents-core/blob/4.4.x/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java#L570]

{code:java}
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()
            .setConnectionManager(cm)
            .build();
    cm.cleanup();
}
{code}

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

Oleg 

> 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
(v7.6.3#76005)

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