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