Uploaded image for project: 'HttpComponents HttpCore'
  1. HttpComponents HttpCore
  2. HTTPCORE-702

Improve connection limit guarantees

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • 4.4.14
    • None
    • HttpCore
    • Ubuntu 18.04.6 LTS
      OpenJDK version 11.0.11

    Description

      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.

      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:

      {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}}} 

      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.
       

      Attachments

        Activity

          People

            Unassigned Unassigned
            Beko Nikola Bekcic
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: