[rabbitmq-discuss] Channel thread-safety

[Tim Watson]

Actually, that's not quite right. Channels *are* thread safe in the 
java-client, and can be shared across multiple threads if you wish. As 
the Java client API documentation 
(http://www.rabbitmq.com/api-guide.html) states however:

"Channel instances are safe for use by multiple threads. Requests into a 
Channel are serialized, with only one thread being able to run a command 
on the Channel at a time. Even so, applications should prefer using a 
Channel per thread instead of sharing the same Channel across multiple 
threads."

In other words, because the transmission of AMQP commands via a given 
Channel is serialised, there is probably little or no benefit in sharing 
the channel between threads.

Unfortunately, whilst we've updated the documentation on the website to 
reflect this change (which was merged in September 2011 and released in 
2.7.0) we appear to have missed the javadocs for the Channel class - I 
will get that fixed asap so as to avoid any further confusion!

Cheers,
Tim

On 10/23/2012 02:08 AM, Laurent Vauthrin wrote:
> Thanks for clearing that up!
>
> On Mon, Oct 22, 2012 at 3:46 PM, Michael Klishin 
> <michael.s.klishin at gmail.com <mailto:michael.s.klishin at gmail.com>> wrote:
>
>
>
>     2012/10/22 Laurent Vauthrin <lvauthrin at gmail.com
>     <mailto:lvauthrin at gmail.com>>
>
>         My questions are:
>         1. Should we be using a channel per thread considering that
>         we're synchronizing the basicPublish call anyway?
>
>
>     Yes. Channels are just integer on the wire and a little bit of
>     memory allocated on the JVM heap. They are very cheap
>     for all intents and purposes and you are much more likely to max
>     out your OS and hardware resources (assuming 1 channel per JVM
>     thread) before
>     you run into issues with channel objects.
>
>         2. Can we just share one channel across all threads and not
>         synchronize the call to basicPublish?
>
>
>
>     No. The real issue with shared channels is that large messages
>     will result in multiple protocol frames being sent
>     for a single basicPublish operation. When publishing on the same
>     channel from multiple threads, this may result
>     in frames being delivered out of order:
>
>     T1 => basicPublish => [Frame11] [Frame12] [Frame13]
>     T2 => basicPublish => [Frame21] [Frame22] [Frame23]
>
>     may result in the following delivery order, all on the same channel:
>
>     [Frame11][Frame21][Frame12][Frame13][Frame22][Frame23]
>
>     and because all frames are on the same channel, RabbitMQ won't be
>     able to tell how to reconstruct your messages.
>     -- 
>     MK
>
>     http://github.com/michaelklishin
>     http://twitter.com/michaelklishin
>
>
>     _______________________________________________
>     rabbitmq-discuss mailing list
>     rabbitmq-discuss at lists.rabbitmq.com
>     <mailto:rabbitmq-discuss at lists.rabbitmq.com>
>     https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20121023/5eefd15e/attachment.htm>