[Bug] Some statistical items should also be deleted to prevent memory leakage when a topic or group is deleted

[RongtongJin]

Before Creating the Bug Report

• [X] I found a bug, not just asking a question, which should be created in GitHub Discussions.

• [X] I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

• [X] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

All platform

RocketMQ version

5.x

JDK Version

All JDK version

Describe the Bug

The previous issue is #8432, but after enabling autoDeleteUnusedStats, a small number of metrics still experienced leaks. It was eventually discovered that some metric items were overlooked during the deletion of Topics or Groups.

Steps to Reproduce

The frequent creation and deletion of topics and groups, while also sending and receiving messages.

What Did You Expect to See?

No memory leakage

What Did You See Instead?

Memory leakage

Additional Context

No

[yx9o]

I used mqtt in version 4.9.8 and also found memory leaks. https://github.com/apache/rocketmq-mqtt/issues/287

[RongtongJin]

I used mqtt in version 4.9.8 and also found memory leaks. apache/rocketmq-mqtt#287

The issue indeed exists; is there a solution to fix it?

[yx9o]

I used mqtt in version 4.9.8 and also found memory leaks. apache/rocketmq-mqtt#287

The issue indeed exists; is there a solution to fix it?

I can think of two possible solutions:

1. Change rmq and add a scheduled task. Because the client changes on the mqtt side cannot be sensed, the lmq-related ones can only be removed mindlessly on a scheduled basis
2. Change mqtt. When the client goes offline and disconnects, notify the broker to remove it (recommended)

[RongtongJin]

I used mqtt in version 4.9.8 and also found memory leaks. apache/rocketmq-mqtt#287

The issue indeed exists; is there a solution to fix it?

I can think of two possible solutions:

1. Change rmq and add a scheduled task. Because the client changes on the mqtt side cannot be sensed, the lmq-related ones can only be removed mindlessly on a scheduled basis
2. Change mqtt. When the client goes offline and disconnects, notify the broker to remove it (recommended)

I also think the second option is better. It may be necessary to adapt the new interface to clean up the resources of the lmq queue, or directly implement it in the deleteTopic and deleteSubscriptionGroup methods.