Multi-threading behavior with v7 client

[qrli]

In previous versions, the doc states that a model/channel must be only accessed from one thread at a time.

In the v7 implementation, I see that the .NET Channel classes are used internally and there is an internal thread to actually process and send commands to server. My gut-feeling is that now it is safe for my code to call methods on a RabbitMQ model/channel object from different threads without locks in my code. On the other hand, the async API makes it impractical to do locks, where the lock will span over awaits which is a recipe for deadlock.

Just want to confirm whether my understanding is correct. Thanks in advance.

[lukebakken]

On the other hand, the async API makes it impractical to do locks, where the lock will span over awaits which is a recipe for deadlock.

Use SemaphoreSlim instead of lock. This code base uses SemaphoreSlim in several places.

My gut-feeling is that now it is safe for my code to call methods on a RabbitMQ model/channel object from different threads without locks in my code.

What would be extremely useful to this project is for you to use the latest RC (https://www.nuget.org/packages/RabbitMQ.Client/7.0.0-rc.8), remove the locks from your code, and report back.

After a quick review of the SocketFrameHandler class, I think you're correct. I will add some tests to confirm.

[qrli]

Use SemaphoreSlim instead of lock. This code base uses SemaphoreSlim in several places.

Ahh, that's great to know. I'll have a try.

[michaelklishin]

For multi-frame operations (namely basic.publish) and synchronous (as in, having a protocol response) protocol methods (e.g. queue.declare or queue.bind) it is a extremely likely that even with socket-level synchronization in the library you will run into obscure issues, async API or not.

Bunny (the most popular Ruby client) does exactly this: it synchronizes socket writes because not doing so is not practical in the context of certain Web servers, but sharing channels between threads is not supported. Two levels of locking on the hot code path and the complexity of a concurrent continuation implementation (in Ruby, it can be much easier to reason about in C#) were not worth the effort. My point is that socket-level synchronization is not enough in practice with key operations mentioned above.

[qrli]

Good to know. Thanks.

I don't do consuming side in multi-threads and no reason to do so. My case is for message senders - multiple threads (from HTTP requests) are producing messages. When I was trying to serialize that into a single thread with .NET's Channel, I found the RabbitMQ client library is already using Channel internally, thus the question. I'll take your advice and try SemaphoreSlim.

[lukebakken]

You should benchmark what happens if you create a new IChannel instance per HTTP request. You should also consider using an ObjectPool to cache existing IChannel instances.

Finally, I'm 99.99% sure that publishing is thread-safe when using a shared IChannel instance.

[rhuijben]

Haven't seen issues in our application, using a single channel now.
(We switched from EasyNetQ's advanced queue code to directly using the v7 api recently.)

[lukebakken]

@rhuijben thank you for chiming in!

What are you doing with the shared channels? Just publishing? Consuming?

[rhuijben]

Publishing and consuming.

I just use a single channel on a single connection per service instance now, and this has been more stable+a bit faster than our previous implementation that had many models over two connections, for the last few weeks.

The performance is probably mostly removing unneeded layering though.