How to make RabbitMq.Client resilient?

[alrz]

In order to be able to use the client directly (that is, not using a third-party wrapper) we need to be aware of the behavior when things break. For instance, IIRC the channel closes when the consumer takes too long. That's probably one case I've seen out of many. I'd like to be able to use the pure client without explicitly handing connection/channel events and have it resilient to failures by default. It seems like Autorecovery does address this to some extent but I think there's still failure points that need to be handled explicitly.

If my understanding is correct, I think it would be nice if we had something like RabbitMq.Client.DependencyInjection to add the client to a worker/aspnetcore app and not worry about connection/channel failures, preferably avoiding a service restart.

[lukebakken]

Hello, thanks for using RabbitMQ and this library.

Your discussion is very general. If you have specific issues, or suggestions, please list them. Otherwise, there's not much I can do with it.

For instance, IIRC the channel closes when the consumer takes too long.

Yes, this is a RabbitMQ feature. Consumers are not allowed to "hang onto" messages past the consumer timeout interval. This is to prevent excessive disk usage. If your applications time out in this manner, it is indicative of a bug, or that you need to re-think how your applications consume messages.

Autorecovery does address this to some extent but I think there's still failure points that need to be handled explicitly

There are situations that can't or shouldn't be automatically recovered.

In general, applications that wish to use this library directly should always subscribe to all events on connections and channels, and do something with them, even if it is just logging that the event happened.

I will re-open this discussion if much more specific suggestions or examples (ideally, with code to reproduce) can be provided.

[michaelklishin]

"The channel closes when the consumer takes too long" is a server protection mechanism that is documented. The default timeout is 30 minutes and it can be increased further if really necessary.

This client already does more than an "average" one, in terms of publisher-side data safety by implementing a more or less transparent tracking of publisher confirms.

Everything else is either trivial (use consumer acknowledgements and provide a list of cluster nodes to try to connect to), or so application-specific that a library cannot and should not try to automagically recover.