[rabbitmq-discuss] Channel best practices

[Michael Klishin]

2013/9/23 Mike Hadlow <mike at suteki.co.uk>

> Does the channel concept exist only to support multi-threaded
> applications, or does it have some other purpose?
>

It was added to avoid having N TCP connections from the same client in case
it needs to have multiple logical connections.


> If I marshal all calls to a channel onto a single thread in my application
> code, is there any problem with simply maintaining a single channel for all
> declares, publishes and consumes?
>

Should be fine.


>
> Additional questions:
>
> 1. Should each basic consume be invoked on a dedicated channel?
>

If you want to have N consumers from the same OS process, it's not strictly
necessary.


> 2. Do I need to basic.ack on the same channel on which I invoked
> basic.consume?
>

You must ack/nack/reject on the same channel the delivery was on because
delivery_tag is
scoped per channel.

A good reason to use more than one channel is error handling, which in many
cases is per-channel.
For example, if you expect an exception for one operation that you can
recover from, you can use
a separate channel to make sure the connection closure caused by the
exception does not affect other operations in the same VM.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130923/af810d83/attachment.htm>