[
https://issues.apache.org/jira/browse/HTTPCORE-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17452365#comment-17452365
]
Nikola Bekcic commented on HTTPCORE-702:
----------------------------------------
Тhank you for the quick reply, [~olegk]!
{quote}but please note any API changes including new configuration options can
only be made in master (5.2)
{quote}
Understood. As previously mentioned, I will try to improve the connection limit
guarantees with the smallest possible changes. I think that is doable *without*
any API changes but I might be missing some historical context as this is the
first time I am getting involved.
{quote} I suppose the new behavior should be configurable but not default.
{quote}
It was my initial thought also but honestly, now I think that it's reasonable
to have it as a part of the default behavior. From the user perspective, I
believe that having strict (or stricter) connection limit guarantees is what is
expected. That is especially true now as in version 5, StrictConnPool is used
as a default pool implementation.
Please note that I have already made changes based on the *4.4 branch*
({+}4.4.12{+} is the version we are using in production currently) but was able
to reproduce the same issue on the latest *5.1.2* version with the
{*}StrictConnPool{*}. Having the name and intention in mind I believe that
changes should be committed to master as well (or we should do something else
about it).
Nikola
> 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
> Priority: Minor
> Labels: volunteers-wanted
> Fix For: 5.2-alpha3
>
>
> 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: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
