[rabbitmq-discuss] FW: Multiple consumers

Sat Jul 28 09:00:41 BST 2007

Ben,

Apologies for the delay in responding to you - I have been very busy
this week.

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

> OK, based on this discussion here's the latest patch.

Looks generally ok, with one caveat: Client channels ought to be
processes. That way you don't funnel everything through a single
process.

In the direct API the client channel processes ought to be the same as
the server channel processes, i.e. the user's client code would interact
directly with the server channel processes.

> So I opted to handle the reception of a consumer pid as an extra field
> in the mainloop_without_framing/1 function in the channel.

You appear to be changing the channel's writer pid with every
basic_consume. That doesn't look right.

think the direct consumer case should actually look like this:

  consumer <-- queue

(which is simpler than what I proposed before)

Queue processes maintain a list of consumer processes. In the direct API
that's the only mapping you need. In the network API the client channel
processes maintain a mapping from consumer tags to consumer processes.

The question is what should the writer_pid be set to in the direct API?

One possibility is to set it to the caller's pid when doing rpc. That
way rpc can be implemented like this:

rpc(ChannelPid, MethodRecord, Content) ->
  ChannelPid ! {method, MethodRecord, Content, self()},
  receive
     {send_command, MethodRecord} -> MethodRecord
     ...
  end.

The tricky bit is how to deal with asynchronous non-consumer events,
i.e. cases where a channel/transaction/queue processes sends messages to
a writer process as part of something other than an rpc or message
delivery. Perhaps the writer_pid should be set to the channel pid?  That
would require some pretty careful coding to avoid deadlock.

I reckon it may be easier to tackle the network API first. It is the
more general case and the refactoring it forces will inform our thinking
on how to best implement the direct API.

Matthias.