[rabbitmq-discuss] FW: Multiple consumers

[Ben Hood]

Matthias,

> > I orginally started with that variant, then I thought it might be
> > ambiguous when you are connecting to more than one AMQP server.
>
> It would not be ambiguous because the Channel process will have been
> created by the Client/Connection/Reader process, which equips it with
> references to the correct Reader, Writer for a particular connection.

That is true, but what happens when you have connections to mulitple
remotes servers or you have one connection via the direct API and
another via the networked API (e.g. if you were connecting to rabbitmq
directly and interacting with say QPid remotely)?

Example:

User --> ChannelProcess(N) --> ServerReader/Writer
User --> ChannelProcess(N) --> Network --> Server

In this example a user has opened channel N using the direct API and
has opened another channel N with a remote network server. How does
the user distinguish between the two Pids that they would have to use
in conjunction with an API call? If you just supplied the channel as a
parameter, the channel Pid resolution wouldn't work, unless the user
stores the Pid of the spawned channel process when they start it. Then
in that case, for the direct API since you have a process per channel,
you wouldn't even need to supply the channel. You would only need the
channel in the network case, where you have a single socket handling
process.

> The problem with this is that basic.consume_ok should be returned as the
> response to the caller, not sent to the subscriber. That is what is
> happening in the Java client.

This is not happening. To solve this I've introduced the concept of an
acknowledgement pid that the *_ok methods get dispatched to, so the
basic.consume_ok goes to the caller and the actual message gets
delivered to the subscriber. This is what I described in the mail that
got returned which I re-incorporated into this discussion thread.

>
> I reckon the easiest way  to accomplish this in the direct client is to
> shift the responsibility of sending the consume_ok from the queue to the
> channel, as indicated in my previous email. That is on our todo list,
> but it won't get done in time for the next release.

That would be another way of solving it:

case rabbit_amqqueue:basic_consume(Q, NoAck, ReaderPid, WriterPid, AckPid,
					       ConsumerTag, ExclusiveConsume, NoWait) of
		{ok, ActualConsumerTag} ->
		    put_consumer_mapping(ActualConsumerTag, ActualQueueName),
		    %% send consume_ok here
		    State;

>
> With that change in place, the above code then needs to be tweaked so
> that the handling of the basic.consume method gets access to both the
> WriterPid (for sending back the consume_ok) and the SubscriberPid (for
> passing to the queue).

Well, as I've stated above, I solved it another way so it's not
currently an issue, but to change it to the way you suggest would be
easy enough anyway. I'll wait direction if you think you are going to
revisit this area after the next release.

Ben