Memory leak caused by an increase in ClientState instances of the apache-camel-mqtt component

Question

I am using camel version 3.14.6, project language is Java, framework is springboot, and I referenced <dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-paho-mqtt5-starter</artifactId> package，I did not do any configuration for the link between camel and mqtt, the following is the configuration map enter image description here spring manages the rest. My current business scenario is: the project is started with the from("topic? client-id=abc") to subscribe to consumer messages, topic uses wildcards to implement data processing for all messages. Some devices connect to my tcp service directly and send messages to the corresponding topic through the ProducerTemplate after the data is processed. The current problem is that the increasing number of ClientState instances causes memory leaks. It is reasonable to say that my project subscribed to only a few dozen messages when it started. All subsequent links were created by camel when sending messages to mqtt, and the clientId I saw on the mqtt server was also a random string generated by camel, but these links were not closed. When I was using mat to analyze memory files,the ClientState instance given a leak alert was overoccupied.

I tried using springboot to manually manage camel's beans. Here is the code map [enter image description here](https://i.stack.imgur.com/ezMx6.png) from("").threads().executorServiceRef(" MQttProfileExecutor ") to use the thread pool I configured, but it doesn't seem to do much, My ProducerTemplate destruction class is also not in effect.

So I would like to know if spring can manually manage and release ClientState instances, as it seems to do very little self-destruction, or are there any configuration properties that support self-destruction of instances, or any suggestions on the best way to handle this

Answer 1

I used the session-expiry-interval attribute because some of my business scenarios have permanent subscriptions, their messages are received continuously, and others are sent and then broken off, so I set this attribute to 0, that is, the network disconnection directly closes the session, this should be solved. Whether the specific effect is waiting for my follow-up observation