[rabbitmq-discuss] FW: Multiple consumers

Sun Jul 29 08:50:53 BST 2007

Ben,

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

>> > if you use the named approach, the API might look this:
>> >
>> > access_request(Channel, Host, Realm)
>>
>> I'd like to see
>>   access_request(Channel, Realm)
>
> 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.

> The current code is catering for the basic_consume call, so it sets
> the writer pid to the actual subscriber and the ack_pid to process
> handling the protocol for a channel:
>
> mainloop_without_framing(State) ->
>     receive
> 	{method, MethodRecord, Content} ->
> 	    State1 = handle_method(MethodRecord, Content, State),
> 	    mainloop_without_framing(State1);
> 	{method, MethodRecord, Content, SubscriberPid} ->
>         WriterPid = State#ch.writer_pid,
>         State0 = State#ch{writer_pid = SubscriberPid},
> 	    State1 = handle_method(MethodRecord, Content, State0),
>         State2 = State1#ch{writer_pid = WriterPid},
> 	    mainloop_without_framing(State2);
> 	Other ->
> 	    rabbit_log:error("Unexpected ch~p content: ~p~n",
> [State#ch.channel, Other]),
> 	    mainloop_without_framing(State)
>     end.

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.

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.

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

> BTW, I've implemented the process per channel model and now I'm
> looking at paramterizing the ampq_client to cater for the network
> case. Will let you know when something useful comes to life.

Cool. It will be interesting to see what changes to the design this
forces.

Matthias.