Topology not recovering

[fvoronin]

I have a problem with topology recovering after a network error occurred. Only connection was recovering 😞.

For example: use Client and Server. Client periodically send message to Server through test.for-sever exchange witch binded to test.server queue. Server consume that messages from the queue.
Please look at the gist with examle code and output log. There are tcp-proxy class for network problem simulation.

Connection was recovering, but exchanges and queues was lost.

RawRabbit version="1.10.3"
RabbitMQ.Client version="4.1.3"

[pardahlman]

Hello, @fvoronin - thanks for reporting this, especially the informative gist 👌

RawRabbit delegates recovery to the underlying (official) client (RabbitMQ.Client). By default, AutomaticRecoveryEnabled and TopologyRecoveryEnabled are both set to true.

Looking at the configuration used, I see that you have set AutoDelete to false for queues. This means that the queue will be removed once all clients/consumers are disconnects from it I'm guessing that what happens is that the consumer disconnects, and the queue is deleted and hence not recovered. It would be interesting to see if everything works as expected with AutoDelete set to false.

Hope this helps!

[fvoronin]

Thanks for reply, and sorry for a my late response.

If set AutoDelete queue parameter to false, test works fine - messages are delivering to server when network connection restored. And i think, that in this case no TopologyRecovery needed, because Topology was not changed 😊

In our solution we need AutoDeleted queues.
I write same test, but use only official client (RabbitMQ.Client). Please look at the new gist.
Connection and topology was restored successfully.

[fvoronin]

I conducted an investigation :)
I assume that the problem is related to TopologyProvider class. In particular, with disposing of the _channel, with which the entire topology is created.
Please look at the rabbitmq-dotnet-client issue comment

An explicitly closed channel assumes it's no longer needed, and likely so is everything that was declared on it

If we do not dispose the _channel in the TopologyProvider, then almost everything will work. Almost means that we need to wait for the RabbitMQ.Client to restore the topology before publishing the message by busClient.PublishAsync.

[pardahlman]

Thanks for digging into this, @fvoronin. This is news for me, as I've been using another "definition" for auto-delete:

autodelete = delete when the last downstream thing (i.e. consumers for a queue, or queues for an exchange) goes away. Note that this isn't bound to channels or connections at all really.

By this definition, the queue shouldn't be deleted if it has active consumers. Anyways, it makes sense to align with what the RMQ team says. Not sure if the fix is going to be made for the 1.x branch, as current efforts are placed in the upcoming version 2.0.

[pardahlman]

The topology channel is no longer disposed in 2.x. If at all possible, upgrade to the latest version 👍