RabbitMq consumers number grows after a period of time

Hi, I installed a single instance of a service that uses RabbitMq as a broker, and after a period of time, I noticed the number of related queue consumers grows. Why is it happening? How can I prevent this behavior?

Nservicebus version: 7.5.0
Nservicebus.RabbitMq version: 6.1.1

Hi @Rasul_Abbasi,

Could you share a screenshot of the management interface showing the consumers you are talking about?

Have you looked at the log files for the endpoint that is consuming messages from that queue? I would expect to see some entries in there related to some problems based on the behavior you are describing.

Thanks for replying, here is an image from the consumer list. In 192.168.82.58 server, I just installed two instances but as illustrated in the picture, there are five consumers bound from this server.
Is it because of the prefetch count? I think there is a relationship between concurrency and CPU ability.
What should I look for in log files?

@Rasul_Abbasi

I was hoping to see the full details of the consumer tag, which you’ve appeared to have redacted in your screenshot.

If you’re not comfortable with sharing unredacted screenshot publicly, please consider opening a support case where we can dig into the details.

In general, you should see a single consumer per endpoint that is running. Nothing related to concurrency alters that.

@bording
They have the same name which is “AF-APP31 - Pap.WebPush.UniqueSending” (the name of the server + queue). I just don’t want the picture to reveal the domain but in the comments, I can say about the details.

The fact that you are seeing that many consumers very heavily implies that you actually have more endpoint processes running than you think that you have.

How are you starting/running those processes? Could it be starting more of them than you think?

Regarding log files, the thing to be looking for would be any warning or errors that indicate some sort of connectivity problem to the broker. It shouldn’t be possible for the reconnecting logic to end up with having more than one consumer active in a single endpoint, but if you can 100% rule out that there aren’t actually 5 endpoint instances running, then that’s the only other thing that could be something to investigate.