Hi, community
Recently, we found a problem when we were stress testing the mqtt service.
When there are too many consumers and the clientId is changed after multiple restarts, the message cannot be produced and consumed. The error reported by rmq is as follows:
After analyzing this, we found that a large number of ConsumeQueue in memory are /retry and /p2p. This problem occurs because the client will subscribe to the secondary topics /retry and /p2p by default, and they are bound to the clientId. Then, when the client is offline, the broker is not notified to remove the secondary topic from the consumeQueueTable, and the count of maxLmqConsumeQueueNum will not be deducted, which causes it to continue to increase, thereby triggering the exception of maxLmqConsumeQueueNum exceeding the limit.
The rmq version we use is 4.9.8
The mqtt version we use is Release-1.0.1
Hi, community Recently, we found a problem when we were stress testing the mqtt service. When there are too many consumers and the clientId is changed after multiple restarts, the message cannot be produced and consumed. The error reported by rmq is as follows:
After analyzing this, we found that a large number of ConsumeQueue in memory are /retry and /p2p. This problem occurs because the client will subscribe to the secondary topics
/retryand/p2pby default, and they are bound to the clientId. Then, when the client is offline, the broker is not notified to remove the secondary topic from theconsumeQueueTable, and the count ofmaxLmqConsumeQueueNumwill not be deducted, which causes it to continue to increase, thereby triggering the exception ofmaxLmqConsumeQueueNumexceeding the limit.The rmq version we use is 4.9.8 The mqtt version we use is Release-1.0.1