[rabbitmq-discuss] Channel best practices

Mon Sep 23 11:40:06 BST 2013

On 23 Sep 2013, at 11:20, Mike Hadlow wrote:

> Hi All,
> 
> Are channel best practices for connected RabbitMQ clients published anywhere? I understand the threading limitations, that channels should not be shared between threads. Does the channel concept exist only to support multi-threaded applications, or does it have some other purpose?
> 

The channel concept exists (in AMQP) to provide a lightweight alternative to having one TCP connection per client, since the latter are resource intensive (to both client and server's detriment). Multiplexing multiple "clients" over a single TCP connection turns out to be a fairly common approach amongst network intensive applications. Channels also provide a unit of atomicity with regards message ordering, i.e., messages are always fully (FIFO) ordered from client to server over a single channel, whereas there are no ordering guarantees regarding messages concurrently sent (or delivered) over multiple channels.

> 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?
> 

One problem you might run into relates to the answer I've given below about correlating ACKs with the correct channel.

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

That's not strictly necessary, though neither is it wrong. Depending on your application logic, you might find that introduces unnecessary overhead (in terms of threads and associated synchronisation primitives used in the client and/or additional resource use on the server), so if I were you I would only do it if it is (a) necessary or (b) significantly simplifies your client code. Remember that a channel provides a FIFO ordering guarantee, so having multiple consumers on a single channel means that you're potentially dealing with messages from more than one source queue, in which case you might inadvertently introduce a serial bottleneck. 

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

Yes, that is absolutely necessary. An ACK sent on another channel to the one on which the delivery was received will be treated as a channel error.

Cheers,
Tim