[rabbitmq-discuss] FW: Multiple consumers

[Ben Hood]

Matthias,

> > a) pass the Pid of a subscriber into the channel
> > b) have subscription events get sent back to the client process, which
> > then in turn can forward them on to a subscriber.

> In the Java client code it is the *channel* that keeps handles to
> Consumers, and dispatches messages to them. So that is actually closer
> to option (a).

I agree that the client side terminology uses a *channel* that
dispatches to consumers, but I think we may may actually be talking
about the same thing. The analogy I was trying to draw in option (b)
was that in the Java client you have a thread that deframes data off
the wire and passes it on to event consumers. With the erlang client
in option (b), the server sends all events to the client process which
in turn would multiplex them to the consumers registered with the
client. The difference is that only the client knows about the
existence of the physical consumer process. Option (a) could make use
of the fact that as an erlang process, the server channel could
directly send an event to a consumer process, thus bypassing the
client process as follows:

client                       server

reader 1..n  <-----  writer 1..n

So the question I was trying to ask was: Does this direct dispatch
gain you anything? Certainly it is less intrusive to keep it as you
have illustrated below, at the (potentially negliable) cost of
shoveling data from the server writer to the consumer via the client
reader:


client processes       data shovel        server

consumer 1..n <----- reader <---------- writer 1..n

>
> Ultimately, certainly when moving to a full networked client, you will
> end up with reader/channel/writer processes that are wired like this
>
> client         server
>
> reader <------ writer1..n
>
> channel1..n    channel1..n
>
> writer1..n --> reader
>
> Consumer processes would hang off the client channel1..n processes.
>
> The "wires" may either be straight Erlang communication, bypassing any
> framing and marshalling, or fully-fledged AMQP communication of TCP/IP
> etc involving framing and marshalling.

I like the way you represented this, it helps in clarifying the interaction.

Ben