[rabbitmq-discuss] Exchanges, Routing, and AMQP

Tue Oct 21 17:40:04 BST 2008

Ben,

On Mon, Oct 20, 2008 at 7:03 PM, Ben Hood <0x6e6562 at gmail.com> wrote:
> On Mon, Oct 20, 2008 at 4:01 PM, Kirk Wylie <kirk at kirkwylie.com> wrote:
>> Personally, I believe that the spec should be changed so that
>> exchanges are nothing other than producer-provided namespaces/groups
>> of related messages, and consumers should bind to exchanges based on
>> the semantics that they want.
>
> I think you may find resonance with some members of the WG on this
> issue. However, moving the routing algorithm to the binding does have
> a practical implication from an implementation perspective. This would
> turn any routing decision into a linear scan of all of the bindings in
> order to perform a match on the routing type :-( You would not be able
> to exploit any type-based indexes.

Well, no, actually, that's not true. That's only true of a naive
implementation of a binding-based system. The RabbitMQ-based
implementation where you're modelling all the primitive AMQP concepts
as direct Erlang processes would definitely suffer from this problem,
but I'm sure you could work out a system where invoking a binding
dynamically modifies the routing table of the exchange.

> This is true, but I think until AMQP goes 1.0, you should, IMHO,
> prioritize design over backwards compatibility.

Agreed completely.

> I think it may not necessary be a good idea to de-characterize an
> exchange to the extent that it merely represents a logical address. If
> you were to do so, you would be automatically precluding semantics
> that you could efficiency build into a custom exchange (e.g. an
> exchange that delivers to a subset of the matching binding - for
> example the shortest queue).

Well, you're talking about a custom routing rule, and conflating that
with an exchange. Custom routing rules are great, and orthogonal to
Exchanges if you decouple exchanges from routing, which is what I'd
really prefer.

> Furthermore, you can bring the consumer driven-ness into the realm of
> your app by having a convention that prevents a producer from
> declaring exchanges - if the exchange doesn't exist, then the producer
> will not be able to send messages to it.

Then the "createExchange" call shouldn't be an assertion, it should
check for a pre-defined configuration point.

Remember, I'm concerned with badly written applications, where they
might even tell you in documentation all the exchanges that they're
using, but they're actually lying. This happens a lot sadly.

Kirk