Uploaded image for project: 'Undertow'
  1. Undertow
  2. UNDERTOW-1222

modcluster Node getMaxCachedConnections should return maxConnections

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 2.0.0.Beta1, 1.4.22.Final
    • 1.4.21.Final
    • Proxy
    • None

      In an Undertow setup with IoThreads = 1, cacheConnections (smax) = 2, maxConnections = 16 and ttl = 10s, Apache HTTP server benchmarking tool load tests reveal:

      • 1 connection: all good, no connections closed
      • 2 concurrent connections: all good, no connections closed
      • 3-16 or more concurrent connections: connections closed before they reach their ttl

      I expect the 3rd to 16th connection to be maintained until they reach their ttl. But this does not happen.

      mod_cluster java documentation:

      smax: Soft maximum idle connection count (that is the smax in worker mod_proxy documentation).
      The maximum value depends on the httpd thread configuration (ThreadsPerChild or 1).
      ttl: Time to live (in seconds) for idle connections above smax

      URL: https://docs.jboss.org/mod_cluster/1.3.0/html/java.properties.html

      Node.java#getMaxCachedConnections() returns the value of NodeConfig.java#getCacheConnections(). NodeConfig.java#cacheConnections is the minimum number of connections to maintain.
      This means that the maximum number of cached connections is set to the minimum number of connections. This is wrong.

      Node.java#getMaxCachedConnections() should return the value of NodeConfig#getMaxConnections(). NodeConfig.java#maxConnections is the maximum number of connections that will be kept alive once they are idle.
      This means that the maximum number of cached connections is set to the maximum number of connections. This is correct.

      Now the Apache HTTP server benchmarking tool load tests reveal:

      • 1 connection: all good, no connections closed
      • 2 concurrent connections: all good, no connections closed
      • 3-16 concurrent connections: connections closed after they reach their ttl

      This is the correct behaviour.

              sdouglas1@redhat.com Stuart Douglas (Inactive)
              frapex Frank de Jong (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: