[rabbitmq-discuss] Best Practices on using Channels?

Laing, Michael michael.laing at nytimes.com
Fri Jul 19 22:19:24 BST 2013


Hi François,

I didn't see anyone else respond so I can tell you what we do.

There are lots of Quality of Service parameters set at the channel level.
Since we have a moderate and stable collection of long-lived
queues/exchanges, and long-lived connections for publishing/consuming, we
typically use a channel per, to allow flexibility re QoS.

One general rule is that a channel should be handled by only one thread. We
use asynch event loop processing so it is normally not an issue for us but
it may be for you.

For asynch RPC functionality we set up a reply_to queue and use the
correlation_id to disambiguate responses. Some people allocate a temporary
queue for this purpose - if you use that model, you would probably want the
temp queues in the same channel and they would then share the QoS
parameters.

Hope this helps,

Michael


On Fri, Jul 19, 2013 at 4:03 PM, François Beausoleil <
francois.beausoleil at gmail.com> wrote:

> I'm currently using two connections to RabbitMQ: one for consumers, one
> for publishers. This is to prevent throttling when the RabbitMQ instance
> triggers it's memory alarm.
>
> What about using channels? One channel per connection, or one channel per
> queue/exchange, or a mix? I realize this is similar to the green thread vs
> os threads in managed VMs. Are there advantages of one over the other?
>
> Thanks,
> François Beausoleil
> _______________________________________________
> 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/20130719/c8f19524/attachment.htm>


More information about the rabbitmq-discuss mailing list