[rabbitmq-discuss] FW: Multiple consumers

Sat Jul 21 23:42:19 BST 2007

Ben,

"Ben Hood" <0x6e6562 at gmail.com> writes:

> Whilst trying to get the channel to send messages to a callback
> handler for the subscription model, I've found that I need to set the
> writer pid in the channel to the pid of the client to do the protocol
> handling (the RPC-style interaction), but in order to get subscription
> working I'm going to have to either
>
> 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.
>
> As far as I can tell, option (b) will be less intrusive into the
> current server implementation at a cost of turning the client into a
> pure data shovel for subscription events. If this overhead were
> negligible, I would run with it, because it means that the channel
> code can remain the same. Also, this is inline with what the java
> client does, because it handles data from the socket, deframes it and
> hands it off to a worker thread. Furthermore, I feel it is also more
> inline with the protocol flow. What do think about taking approach
> (b)?

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).

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.

Matthias.