Is Hutch.publish thread safe?

[theredorm]

We've been using hutch with unicorn and some time ago we switched to puma.
Right now we have something like this in our codebase
class Controller def process business_logic_db_and_redis_calls Hutch.connect Hutch.publish(...) end end
we have default rails app, default ruby, some workers, some threads for puma let it be 10 workers with 10 threads per each worker
basic configuration like host, port, and nothing else for hutch like publisher confirms.
So we have 10 tcp connections and 10 channels, we see it in the rabbit management.
When we start load testing our app, we don't see any weird errors related to bunny or hutch which seems weird as bunny doc says that channel is not supposed to be shared between threads(http://rubybunny.info/articles/concurrency.html#synchronized_writes)
If we go into code we'll see that bunny send_frameset method uses channel-wide mutex(https://github.com/ruby-amqp/bunny/blob/8b700a00b62d4f887f53d4871f019d6d494c5f4d/lib/bunny/session.rb#L1151) and there's a good comment says that this code is thread-safe.
Bunny doc also says

It is, however, safe to process deliveries in multiple threads if multi-message acknowledgements are not used.
it also says
Channels must not be shared between threads.

And this is where i got stuck. Because I have not spent enough time investigating what's going on under the hood in hutch, or our testing methods have mistakes, but for me it seems weird when we don't see promised errors when we share channels between threads.

So the question is using Hutch.publish in puma safe?

[michaelklishin]

Publishing from multiple threads on a shared channel is explicitly not allowed/supported by all AMQP 0-9-1 clients:

• Bunny
• Java client
• .NET client

and so on.

Hutch simply delegates its publishers to Bunny.

[michaelklishin]

In other words, you must add explicit synchronization. Do not use short-lived channels, that will ruin both throughput and latency.