Sharing Channels Between Threads Using Locks

[jorgasto]

Hello!

In the Bunny documentation I cannot quite tell if you guys are saying channels should only be used by one thread EVER or one thread at a time (i.e. using synchronization).

e.g. is it possible for the following script to cause the concurrency issues mentioned in the docs?

class ChannelPool
  def initialize(channel)
     @channel = channel
     @mutex = Mutex.new
  end
  
  def take
    @mutex.synchronize do
      yield @channel
    end
  end
end

pool = ChannelPool.new

Thread.new do 
   while true do
      pool.take do |channel|
        channel.exchange('foo', type: :fanout, durable: true, auto_delete: false)
     end
   end
end

Thread.new do 
   while true do
      pool.take do |channel|
        channel.exchange('bar', type: :fanout, durable: true, auto_delete: false)
     end
   end
end

[michaelklishin]

This code assumes that Bunny::Channel#exchange calls cannot result in any kind of interleaving of frames on the wire. Right now this is generally true, and exchange.declare is a single protocol frame, and Bunny writes frames to the socket with synchronisation.

However, what's the point of declaring exchanges if you are not going to publish anything? And Bunny::Channel#publish produces two or more frames, depending on message size:

[basic.publish] [content header] [body]*

So even with synchronised writes of individual frames, you have to be really careful about not ending up with a sequence like this

[basic.publish 1] [basic.publish 2] [content header 2] [body 2]* [content header 1] [body 1]*

This will cause an unrecoverable connection exception.

It is much safer to simply not share channel instances between threads.

[michaelklishin]

Your code does not handle any possible exceptions that Bunny::Channel#publish may throw. Consider using a block version (Mutex#synchronized).

You can set Bunny log level to debug and see what frames it sends.

[sanghyukkang]

Thank you michael. The code was like a pseudo code just to compare single thread publishing and multi thread publishing. I was wondered how two message frames can be interlaced when the two channel.publish method calls are completely synchronized. There is no concurrent execution of channel.publish even in Case 2. Second channel.publish, no matter which thread is the second, starts after first channel.publish has returned.

[michaelklishin]

There is concurrent execution in your own code (with synchronization, and yet), and thread scheduling order is non-deterministic.

Remove the synchronization and see for yourself. RabbitMQ will log a framing error soon enough

[sanghyukkang]

I know that there is concurrent execution if there is no synchronization. What I meant was that there wouldn't be actual concurrent execution of channel.publish method in Case 2 because of the synchronization. I'm only interested in the case where there is synchronization, whether or not there could be a race condition like the interlaced message frames even with the synchronization.

[michaelklishin]

Bunny does not introduce any concurrency from the moment Bunny::Channel#publish is invoked all the way up to socket write. So in the example above, other than the lack of exception handling, I don't see any obvious concurrency hazard scenarios.