[rabbitmq-discuss] FW: Multiple consumers
matthias at lshift.net
Sun Jul 29 00:21:19 BST 2007
"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
>> 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?
>> 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.
More information about the rabbitmq-discuss