Help debugging strange node crashes with quorum queues #10679
-
I've got a cluster deployed with three nodes that went into a weird state this morning when there shouldn't have been any traffic on the cluster at all. Having a hard time figuring out what's going on at all, but it seems to be related to quorum queues? Using RabbitMQ 3.11.18 management image deployed with kubernetes cluster operator. Here's a dump of the logs from the first crash, but it appears the node kept retrying and crashing (with successful client connections getting logged in between). The quorum queue ended up in a bad state (minority in cluster) even though two other nodes were supposedly up.
Any help with this would be appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
We do have classic queues on that node as well. Is this possibly related to this issue fixed in 3.11.19?
|
Beta Was this translation helpful? Give feedback.
-
RabbitMQ 3.11 is out of community support, and 3.11.18 specifically is ten patch releases behind. |
Beta Was this translation helpful? Give feedback.
The line in question. It is one of the steps during consumer registration.
I do not see any obvious connection with #8564. There is no queue filtering going on when a consumer is added, the name of the queue is already known (client-provided).
In any case, the response is still: 3.11 is out of community support, and you are ten patches behind in that series alone.