Topology recovery after switching from a node to another: channel error, queue no found #14564
-
Describe the bugHi, I have an error with the Topology Recovery on network fails using multiples nodes. I'm trying to successfully recover the connection after switching from one node to another when the first node is shutdown. RabbitMQ version: 4.1.4 Reproduction steps
Expected behaviorBehavior wanted: when the client A is disconnected from the node 1, it will automatically reconnect to the node 2 and then recover the topology. What happens: when the client A is trying to recover the channel it fail with a channel error and the reason for it is that the queue is not found. Additional contextI have the following questions: Is there a bug in the automatic recovery ? Regards. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
@hyfara this is an ages old problem with client connection recovery and non-replicated queues being moved around when nodes stop. The behavior will vary depending on queue properties, e.g. exclusive queues will be deleted concurrently with clients trying re-declare them on different nodes. Exclusive server-named queues won't have any issues. The solution is to not use non-replicated queues with well-known names, so, either use a replicated queue type or use transient exclusive server-named queues. RabbitMQ cannot know what clients will do next, so this is a fundamental conflict between anything that RabbitMQ does and what clients do at the same time. But replicated queues (plus channels and sessions) handle this scenario, and in the case of exclusive server-named queues, the uniqueness of the name means that there won't be any conflicts. Oh, and please never file issues for questions in the repos that have discussions enabled. |
Beta Was this translation helpful? Give feedback.
@hyfara this is an ages old problem with client connection recovery and non-replicated queues being moved around when nodes stop.
The behavior will vary depending on queue properties, e.g. exclusive queues will be deleted concurrently with clients trying re-declare them on different nodes. Exclusive server-named queues won't have any issues.
The solution is to not use non-replicated queues with well-known names, so, either use a replicated queue type or use transient exclusive server-named queues.
RabbitMQ cannot know what clients will do next, so this is a fundamental conflict between anything that RabbitMQ does and what clients do at the same time. But replicated queues (plus channels a…