[Documentation] "Channel-level exceptions" and channel recovery state

[HeathJared]

Is your feature request related to a problem? Please describe.

The RabbitMQ documentation frequently refers to "Channel-level exceptions" when discussing connection and channel recovery and describes several situations where these exceptions may need to be handled differently.

I am unable to find a list of exceptions that are considered "Channel-level exceptions" either through documentation or reviewing the source code for base classes, etc.

Describe the solution you'd like

I would like any or all of the following:

• Documentation explicitly listing exceptions that are considered "Channel-level exceptions"
• A way to determine if a channel is closed, but still recoverable, versus a channel that is closed and un-recoverable.

Describe alternatives you've considered

Add an IsRecoverable property to the IModel and handle updating it internally.

Additional context

I have a use case where I am pooling channels for re-use by an ingestion API. It is my understanding that when a channel is closed due to a "Channel-level exception" that it is not recoverable and needs to be disposed instead of returning it to the pool. Meanwhile, channels that are closed, but recoverable, could still be returned to the pool to prevent churn (especially during a temporary loss of connection).

I currently have no way to reliably distinguish between these two situations.

[lukebakken]

A way to determine if a channel is closed, but still recoverable, versus a channel that is closed and un-recoverable

If a channel is closed by RabbitMQ, it can never be recovered.

[HeathJared]

Thanks for your input and work on the client. I will take another look.

[lukebakken]

For automatic recovery, channels are always recovered, but they are not the same channel within RabbitMQ. This library re-uses the IModel instance for the new channel in RabbitMQ, and updates its internal state for the new RabbitMQ channel. This is transparent to the user. So, you should be able to return your IModel instances to the pool all the time.

So, if you find a situation that doesn't work as expected, please let me know.

[HeathJared]

If that is the case, that is good news. I will let it run under stress for a few weeks and let you know if I encounter a channel that did not recover as expected.

Most of my understanding was based strictly on the statements from the RabbitMQ documentation. If this library handles the problem automatically that is excellent.

Thanks and good luck on 7.0.

[lukebakken]

If you have time, I suggest migrating your code to use the latest version 7 RC - https://www.nuget.org/packages/RabbitMQ.Client/7.0.0-rc.11

I intended to ship that version today but there are some small API changes coming. Version 7 works much better than version 6 in pretty much every way, especially in its use of the thread pool.

[HeathJared]

I hope to soon. We won't be able to this release cycle, but its on the list to revisit soon (Q4 hopefully) along with some other changes and optimizations of our usage of RabbitMQ. Looking forward to it.

[HeathJared]

I wanted to stop by and say good job on the release. The improvements are very much noticed.

I've been stress testing v7 so we can finally migrate from v6 for production and we have been able to remove our channel pools, remove our async confirmation logic, and increase our message throughput anywhere from 30% to 200% depending on the situation. Everything appears to recover as expected.

Benchmarks also greatly improved. For example:

Method	Mean	Error	StdDev
PublishAsync_v6_Net8	217.6 us	4.02 us	5.76 us

Method	Mean	Error	StdDev
PublishAsync_v7_Net9	57.08 ns	0.232 ns	0.206 ns

I'm currently watching this issue while we work towards the next production release including v7.

Just wanted to say thanks again.

[lukebakken]

@HeathJared have you seen anything like what is reported in #1818? I would be very interested to know!

[HeathJared]

No we have not encountered that (yet). Our tests and use cases maybe different.

One of our primary use cases being tested is publishing to channels from multiple threads (high traffic ingestion API with lots of competing publishers) with publish confirmation, so I believe it to be a very similar situation.

If I do encounter this and the ticket is not yet resolved, I plan to add any findings that we dig up.