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.

[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.

[dario-l]

@rhuijben Exactly the same refactoring in our code base we want to do. For now we use EasyNetQ but when we try to run partitioning (with consistent hash exchange) we end up with a lot of nasty bugs.

I was wandering is really one channel enough for every operation? I found this: https://www.rabbitmq.com/docs/channels#flow-control
That's why we are want to use min 2 connections - one for publishing and one for consuming.

We have modular monolith application with well defined and fine grained modules (almost 60 for now).
We are planning to create two connections:

• one for publishers - where publishers from different modules could rent a channel from a pool
• one for consumers - where one queue will have one channel for all subscribers from that queue

Is that sounds reasonable or is it a overkill? 😇

[lukebakken]

@dario-l yes, your publishers and consumers should be on two separate connections, like you state.

[dario-l]

@lukebakken thanks for confirming my decision. 😃

[michaelklishin]

@dario-l a few relevant doc sections, both to help you understand the proposed idea of using separate connections for publishers and consumers, and observe publisher blocking events that usually drive the decision to separate the two:

1. https://www.rabbitmq.com/docs/connections#flow-control
2. https://www.rabbitmq.com/docs/connection-blocked
3. https://www.rabbitmq.com/docs/connections#client-provided-names