Corneliu C commented on HTTPCLIENT-1914:

Hi Oleg,


sounds good! I assume 0 be allowed as a valid value and will preserve the 
reference in the hash map.

Overall: the max per route will then be inherited from default value if one 
re-allocates same route later and also an implementation of the BackoffManager 
will be able to completely mark a host as unavailable.


Is it something it can be done in near future?


Thank you!

> 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