[
https://issues.apache.org/jira/browse/HTTPCORE-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17451758#comment-17451758
]
Nikola Bekcic commented on HTTPCORE-702:
----------------------------------------
Since I was very curious to understand what is going on, I have spent some
limited time reviewing the connection pool implementation. Based on my
analysis, the problem is in the way the connection pool is shrinking only when
a new connection is needed, not before allocating a connection.
I am working on a PR that should change that and (hopefully) improve the
connection limit guarantees (per route) a lot. The plan is to make the smallest
possible changes and then if needed, we can discuss how we can improve on it.
These changes should also improve the way AIMDBackoffManager is working as by
default, AIMDBackoffManager is trying to decrease the number of connections by
half so it is heavily affected by the way the pool is shrinking currently.
Please let me know your thoughts on this.
Regards,
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: Major
> 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]
