Nikola Bekcic created HTTPCORE-702:
--------------------------------------
Summary: Improve connection limit guarantees
Key: HTTPCORE-702
URL: https://issues.apache.org/jira/browse/HTTPCORE-702
Project: HttpComponents HttpCore
Issue Type: Improvement
Components: HttpCore
Affects Versions: 4.4.14
Environment: Ubuntu 18.04.6 LTS
OpenJDK version 11.0.11
Reporter: Nikola Bekcic
Fix For: 4.4.15
h3. Background
To manage the life cycle and re-use HTTP connections we are using
*PoolingHttpClientConnectionManager* with the maximum limit of connections
defined on a per route basis as well as in total.
Using PoolingHttpClientConnectionManager and built-in Java management
utilities, I want to provide our users with the option to dynamically re-size
the connection pool (up and/or down) at runtime without redeploying or
restarting the application with a new configuration.
h3. Issue description
During testing, we found that decreasing the maximum limit of connection per
route does not have (an immediate) effect on the pool size i.e maximum number
of connections per route is staying the same (potentially for a very long time).
E.g. let's use only two routes where the default maximum connections per route
are 10 and the maximum total is 20. At some point, the maximum number of
connections per route will be riched and the number of allocated connections
(available + leased) will be 10. Now, let's say that we need to decrease the
maximum number of connections per route to 5, for any reason. Doing that by
calling either _PoolingHttpClientConnectionManager#setDefaultMaxPerRoute(int)_
or _PoolingHttpClientConnectionManager#setMaxPerRoute(HttpRoute, int)_ will not
change the pool size and the maximum number of connections per route will stay
the same (potentially for a very long time).
This is the sample of the pool stats printed after changing +maxPerRoute+ to 5:
{noformat}
{somehost1:8983={"available":4,"leased":6,"max":5,"pending":0},
somehost2:8080={"available":1,"leased":9,"max":5,"pending":2}}
{somehost1:8983={"available":4,"leased":6,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":2}}
{somehost1:8983={"available":5,"leased":5,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":4}}
{somehost1:8983={"available":5,"leased":5,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":4}}
{somehost1:8983={"available":7,"leased":3,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":5}}
{somehost1:8983={"available":9,"leased":1,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":5}}
{somehost1:8983={"available":9,"leased":1,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
{somehost1:8983={"available":8,"leased":2,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
{somehost1:8983={"available":9,"leased":1,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
{somehost1:8983={"available":8,"leased":2,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":7}}
{somehost1:8983={"available":8,"leased":2,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
{somehost1:8983={"available":8,"leased":2,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
{somehost1:8983={"available":9,"leased":1,"max":5,"pending":0},
somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
{somehost1:8983={"available":9,"leased":1,"max":5,"pending":0},
somehost2:8080={"available":1,"leased":9,"max":5,"pending":6}}}
{noformat}
As you can see, not only that the number of allocated connections per route is
still 10, but also very often the number of leased connection is higher than 5.
In my opinion, this is not what is expected and not really in favor of the
principle of least surprise.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
