[rabbitmq-discuss] FW: Multiple consumers

[Matthias Radestock]

Ben,

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

> The basic.consume_ok ack message gets sent to the subscriber and not
> to the client reader.

I think that may partially be due to some design choices in the
channel/queue implementation that may need revisiting. atm the
consume_ok is sent by the *queue* process. I think it ought to be sent
by the channel process instead - the channel process should be
responsible for sending back responses to *all* synchronous methods.

> What I started to do is to create a named amqp_client server process
> for each channel, so that the protocol flow within a channel is not
> inhibited by the protocol flow from another channel that were both
> using the same amqp_client process. So everytime a channel is opened
> by the user, a gen_server process is started with the name
> chN at host.

Why do the channel processes need to be named?

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

>> You appear to be changing the channel's writer pid with every
>> basic_consume. That doesn't look right.
>
> Do you mean in the mainloop_without_framing function?

Yes.

>> think the direct consumer case should actually look like this:
>>
>>   consumer <-- queue
>>[...]
> So are you saying that you should pass in the consumer's pid to the
> rabbit_amqqueue_process and have that maintain a list of consumers?

rabbit_amqqueue_process already does this.

> I don't see how the networked API will change anything on the server
> side, otherwise wouldn't you have to change the java client as well.

The idea was/is to use the existing server code (rabbit_reader,
rabbit_channel etc) as the basis for the client code. This will require
some refactoring along the lines you have been pursuing so that server
and client can share a substantial part of their code base.


Matthias.