[rabbitmq-discuss] Channel thread-safety

[Tim Watson]

Important addendum: channel calls are *not* thread-safe for 
confirmations: The channel interface is thread-safe now, except for 
counting confirms and checking!

There is an outstanding bug to review this, and the problems associated 
with the fact that publishing and receiving a seqno is not an atomic 
operation.

Anyway - you *may* wish to share a Channel between threads or not, but 
if you're using confirms then you should *not* share a Channel between 
multiple threads. I'll make sure the javadoc changes reflect this state 
of affairs.

Cheers,
Tim

On 10/23/2012 11:29 AM, Tim Watson wrote:
> 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
>
>
>
> _______________________________________________
> 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/6b69fdfd/attachment.htm>