You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We encountered a rarely-happening issue, where there were 100s of (seemingly dead) consumers for a queue, while there should be only a few. And these dead consumers caused rabbitmq server to use 1 GB more memory. As I understand, if the client app crashed, its consumers would be gone too. So these consumers should all belong to those a few living app pods.
After research, I start to suspect the cause is related to Topology Recovery and Consumer Cancellation handling, as both will recreate the consumer. I cannot find doc describing the following:
When connection is lost, the automatic recovery kicks in. Will Consumer Cancel also be triggered?
If yes, it may have 2 consumers recreated. Then I think I can turn off Topology Recovery.
When Topology Recover fails, the doc says it will retry in 5 seconds. Is it possible that the rabbitmq server somehow received the consumer recreation request but just failed to tell the client, thus causing duplicated consumers?
Is it possible that there is race condition between topology recover and consumer cancel? E.g. consumer cancel was received first and before it finishes, topology recovery kicks in.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We encountered a rarely-happening issue, where there were 100s of (seemingly dead) consumers for a queue, while there should be only a few. And these dead consumers caused rabbitmq server to use 1 GB more memory. As I understand, if the client app crashed, its consumers would be gone too. So these consumers should all belong to those a few living app pods.
After research, I start to suspect the cause is related to Topology Recovery and Consumer Cancellation handling, as both will recreate the consumer. I cannot find doc describing the following:
When connection is lost, the automatic recovery kicks in. Will Consumer Cancel also be triggered?
If yes, it may have 2 consumers recreated. Then I think I can turn off Topology Recovery.
When Topology Recover fails, the doc says it will retry in 5 seconds. Is it possible that the rabbitmq server somehow received the consumer recreation request but just failed to tell the client, thus causing duplicated consumers?
Is it possible that there is race condition between topology recover and consumer cancel? E.g. consumer cancel was received first and before it finishes, topology recovery kicks in.
Beta Was this translation helpful? Give feedback.
All reactions