[rabbitmq-discuss] Channel thread-safety

[Laurent Vauthrin]

Thanks for clearing that up!

On Mon, Oct 22, 2012 at 3:46 PM, Michael Klishin <
michael.s.klishin at gmail.com> wrote:

>
>
> 2012/10/22 Laurent Vauthrin <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
> 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/20121022/ddb12951/attachment.htm>