Automatic connection recovery does not re-create explicitly deleted queues

[SunnySourabh]

I am using rabbitmq client 6.8.1 version in dot net project. I am creating queue, exchange and binding programmatically. In the connection factory I have set AutoRecoveryEnabled and TopologyRecoveryEnabled as true.

Once I started my service all queue, exchange and binding created but when I am deleting any queue manually, it is not getting recreated again without service restart.

How and when these 2 properties of Connection Factory works?

[michaelklishin]

@SunnySourabh there is a dedicated documentation section that explains when automatic connection recovery kicks in.

It is not meant to kick in when you manually delete a queue. In fact, it keeps track of the entities you delete specifically to make sure that they are not re-created after connection recovery.

[SunnySourabh]

@michaelklishin
If it will not recreate deleted queues automatically then what is the use of TopologyRecoveryEnabled?

Also in the documentation it is mentioned that **Topology recovery starts after the above actions are completed. The following steps are performed for every channel known to being open at the time of connection failure:

Re-declare exchanges (except for predefined ones)
Re-declare queues
Recover all bindings
Recover all consumers**

What is meant by this?

And I have also used mass transit and in that it recreate queue without service restart. I did some research on that and I found that mass transit use rabbitmq in built feature (which is these 2 properties only) to recreate queue but the same properties is not working in rabbitmq client.

**If these properties is for different purpose then how will I achieve my requirement of recreating queues, exchange and binding without service restart when they deleted manually? **

[michaelklishin]

@SunnySourabh topology recovery recovers the entities that were declared and were not deleted at the time the connection went down. You can choose to opt out of this feature, although at least for consumers it makes perfect sense.

In any case, if you explicitly delete something, RabbitMQ will assume you know what you're doing and delete it, and for connection recovery's sake, delete that queue (or whatever) from the cache so that topology recovery does not re-create them.

I cannot comment on what MassTransit does. The client deletes what it is told to delete, and so do all other clients in the RabbitMQ ecosystem.

If you do not trust your own apps, this is a monitoring problem specific to your company. You use use an AMQP 0-9-1 client to enforce the topology you need, or the HTTP API, or importing a definitions file periodically.

On Kubernetes, this topology operator can be relevant.

[michaelklishin]

Locking because there isn't really much to discuss here: if someone does not trust their apps and must maintain a certain topology, importing a definitions file over the HTTP API periodically (say, once every N minutes) would be one way of approaching it.

This client won't add any special "undo my own deletes" kind of feature. It trust the caller to do the right thing.