We are running a Spring Cloud Stream (SCS) application (Spring Boot 3.5.6, SCS 4.3.0, Micrometer 1.15.4) with a Kafka Binder. It is a fairly huge system

• reading from 3 topics with 48 partitions
• producing into about 150 topics, because the service performs event routing

Producing events is based on the org.springframework.cloud.stream.function.StreamBridge::send method of SCS.

The total number of threads is high, because

• for every consumed partition
• for every topic into which events are produced

there is an additional micrometer-kafka-metrics thread! So we have 200 micrometer-kafka-metrics threads on top of the normal kafka-producer-network-thread, KafkaConsumerDestination and kafka-coordinator-heartbeat-thread threads.

When the application starts , we have 200 threads running. The number of threads increases with the topics into which we have produced at least one event. So after some time, we have 450 threads. This number will still increase over time, when more topics are used for producing events. So, we are afraid, that the number of threads will grow up to 600-800 threads.

A serious problem: In the past weeks we had a situation, where there were 1400 threads with 700 "runnable" and 700 "timed_waiting" showing up in Grafana. Shortly after this, the application stopped working and we had to restart it.

In Stackoverflow, we found only Kafka metrics for Spring-Kafka consumers - possibility to decrease number of threads

We also found out, that there is complicated metric named spring.cloud.stream.binder.kafka.offset in SCS. It might have an influence. But it cannot be deactivated.

So, our questions are:

• Are there similar experiences (thread number increase and not correctly removing them), we are facing with our setup?
• We haven't found an example, how to use the proposed solution in the PR related to the above question. Has somebody been able to get rid of the huge amount of micrometer-kafka-metrics threads?