The value of the tomcat.threads.config.max metric is always -1, irrespective of the configured maximum number of threads

[lass9436]

Bug

my application.yml is

application.yml

management:
  server:
    port: 8080
  endpoint:
    health:
      show-details: always
  endpoints:
    web:
      exposure:
        include: "*"
server:
  tomcat:
    threads:
      max: 400
      min-spare: 10
    mbeanregistry:
      enabled: true

but

http://localhost:8080/actuator/prometheus

I don't know why not working.

Environment

• Spring Boot version: 3.3.0
• JDK version: 17
• OS: Windows 10

solution

my only solution is downgrading spring boot 3.3.0 to 3.2.6

Fortunately, it works successfully in 3.2.6, but I report this bug.

[wilkinsona]

Thanks for the report. The setting is working as expected and Tomcat's thread pool has a max size of 400. The problem is that the metric is incorrect.

I believe that the metric's incorrect due to #36087. It has changed the executor that Tomcat uses so it's no longer internal to the endpoint. This means that it returns -1 for its max threads:

    public int getMaxThreads() {
        if (internalExecutor) {
            return maxThreads;
        } else {
            return -1;
        }
    }

[lass9436]

Thank you for your kind reply. You actually said that Tomcat's maximum number of threads was set to 400, and the metric was incorrect.

3.3.0

But I debugged the part of code you mentioned, and maxThreads is 200. internalExecutor is false as you said. Is the value of 200 here meaningless?

3.2.6

It works normally in 3.2.6.

[wilkinsona]

Yes, it's meaningless unless the executor is internal. What matters is the configuration of the endpoint's executor. If you look at this.executor in NioEndpoint, you should see it using the configured value for its maximum threads.

[mhalbritter]

I've opened https://bz.apache.org/bugzilla/show_bug.cgi?id=69133 - if this is resolved, we can switch back to the default executor and set the queue size for #36087 via a normal setter.

[mhalbritter]

Tomcat has added a setter to set the maximum queue size. When using this setter, this issue should go away. I've opened #41093 for that.