[rabbitmq-discuss] FW: Multiple consumers

[Ben Hood]

Matthias,

> The most direct route actually looks more like this:
>
> rpc:
> caller --> channel
> caller <-- channel
>
> message to subscriber:
> consumer <-- channel <-- queue
>
> Here the channel plays the role of the client channel, server channel,
> and server writer.

Agreed.

>
> That is reasonably challenging to implement. OTOH it will probably force
> the kind of abstractions that would be good to have in any case.

That's why I'm asking the question, because you will need to
incoporate this refactored flow into the flow of the current *socket
based* channel. By passing the messages back to the initiating client
to pass on to the actual subscriber, you don't have to change this.
The only reason I can see right now why you may do this is to optimize
this extra hop away. But as far as I can see, this is only relevant
for the non-networked case, which is why I didn't understand the way
you answered my question about direct dispatching below (because
you're probably envisaging something I haven't thought about).

>
> > So the question I was trying to ask was: Does this direct dispatch
> > gain you anything?
>
> In the networked case we need to add quite a few actors:
>
> rpc:
> caller --> c_channel --> c_writer --> s_reader --> s_channel
> caller <-- c_channel <-- c_reader <-- s_writer <-- s_channel
>
> message to subscriber:
> consumer <-- c_channel <-- c_reader <-- s_writer <-- queue

Agreed.

>
> I reckon the short-circuit route is worthwhile since it simplifies (and
> as a result speeds up) things considerably -- If we are going to have a
> direct client at all, we might as well go the most direct route.

Please understand this in the context of what I said above. I don't
see the relevance of the direct route in the networked case. In the
networked case, you will be using the same socket connection to send
the messages back to the subscriber, so this is exactly the same thing
as the current Java client, as you've correctly pointed out in the
diagram.

So I don't see where the short-circuit route comes into play in the
networked case, only in the non-networked case where you can utilize
erlang message passing.

I hope I haven't totally misunderstood what you have said.

Ben