[rabbitmq-discuss] The relationship of Channels to Consumers

[Ben Hood]

Anders,

On Fri, Sep 19, 2008 at 7:34 PM, anders conbere <aconbere at gmail.com> wrote:
> When building consumers dynamically it's possible to either create a
> new channel for them or to reuse an old one, or to use a pool of them.
> I'm wondering if anyone knows any good practices for dealing with that
> relationship. Is the building channel call expensive?

Not particularly, should scale quite well. Obviously there is a finite
cost, but this is a constant factor is probably negligible.

> Are channels
> capable of handling multiple streams and thus a good fit for use
> across many consumers.

If your consumers are read-only (see comments below), this will work.

You might want to consider the application semantics of connecting
multiple consumers to a single channel. By sharing a channel, you
automatically introduce an implicit binding between each consumer,
because any of them cause the channel to close (either by closing the
channel explicitly or in the case of an invalid command, the broker
may forcefully close the entire channel). You may want these
semantics, or you may not, it depends on your application.

I wouldn't bring it down to a decision based on cost though - as
indicated before, this is most probably going to be an insignificant
consideration.

>
> As I understand it channels are processes on the server side that
> store the state of the connection and help in some way with
> communicating requests and responses. But beyond that I'm just not
> clear about what to do with them.

The wisdom I'm trying to impart on what a channel is and how to use it
from a client perspective follows the logic that I'm describing in the
draft of an upcoming article (available soon, when I get my act
together):

[...]
Although this is not stated explicitly in the protocol, a channel is
the smallest unit of parallelism in AMQP. You should bind an AMQP
channel to a client thread, so a channel is managed as a thread-local
object.

In the AMQP protocol, channels were designed for multiplexing the
sending of multiple unrelated messages from within a single physical
transport, for example from within a single TCP connection. This
mechanism forms the basis of parallel execution of operations that use
a single AMQP client instance.
[...]

However, you are asking about read-only access, so thread safety from
a channel perspective should not be an issue.

Moreover, you are using Erlang, where thread safety is by and large an
non-issue anyway.

HTH,

Ben