Setting 'max-uri-tags' does not prevent unlimited meter growth on any AutoConfiguredCompositeMeterRegistry

[datagitlies]

Spring Boot Version: 3.5.6

Expected Behavior

Setting the management.metrics.web.client.max-uri-tags property should prevent memory leaks. So should setting the management.metrics.enable.http.client.requests property to false.

Actual Behavior

Neither property prevents a memory leak because under certain conditions, the AutoConfiguredCompositeMeterRegistry will accumulate unbounded entries in its meterMap because no MeterFilters are being applied to it. This leads to the eventual exhaustion of heap memory and causes the application to crash.

Replication

1. start the attached sample-project
2. send a couple hundred requests to it via curl: for i in {1..200}; do curl http://localhost:8080/test; done
3. notice the log event in the console:

   OnlyOnceLoggingDenyMeterFilter : Reached the maximum number of URI tags for 'http.client.requests'. Are you using 'uriVariables'?
   

4. capture a heap dump via /actuator/heapdump
5. analyze the heap dump and see
   • the number of elements in the meterMap for the AutoConfiguredCompositeMeterRegistry grows and grows
   • the number of elements in the meterMap for the PrometheusMeterRegistry is static (does not grow and grow)

Conditions:

1. more than one meter registry is configured
   • the attached sample is using micrometer-registry-prometheus + micrometer-registry-jmx but it could be any combination of two or more.
2. the application is generating unique metrics / tags
   • for example: using a RestClient to call a URI without proper use of URI variables (that's the case in the provided sample)

possible cause: 9f21413

See also: #38912 #39070

[ThomHurks]

Interesting, we’ve been using Spring Boot for years and started having OOM issues that may be caused by this, after first analysis. Never read before that using the URI builder is a bad practice with WebClient, as it can cause these issues. Makes me feel the builder should actually be deprecated to force developers to use the API in the “correct” (less error prone) way. Principle of least surprise!

[datagitlies]

Interesting, we’ve been using Spring Boot for years and started having OOM issues that may be caused by this, after first analysis. Never read before that using the URI builder is a bad practice with WebClient, as it can cause these issues. Makes me feel the builder should actually be deprecated to force developers to use the API in the “correct” (less error prone) way. Principle of least surprise!

My .02 - how the URLs are built shouldn't matter or cause a memory leak. There are optimal and suboptimal ways to build URLs for metrics / monitoring purposes. If the suboptimal way is chosen (on purpose or on accident) there shouldn't be this memory leak as a consequence.

[datagitlies]

@philwebb I'm wondering if there has been any discussion on this memory leak.

[philwebb]

@datagitlies Not as yet, we've been focusing on pressing 4.0.0-RC1 issues.