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

["Corneliu C (JIRA)" <ji...@apache.org>]

Corneliu C created HTTPCLIENT-1914:
--------------------------------------

             Summary: 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


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