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

Corneliu C commented on HTTPCLIENT-1914:
----------------------------------------

Hi,

thanks for quick answer; the code sample you provides still does not cleanup 
the maxPerRoute private variable and no other way is currently possible; I 
guess it would be best to cleanup the HTTPRoute reference from maxPerRoute once 
a purge happens?

> 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to