[rabbitmq-discuss] Exchanges, Routing, and AMQP

Fri Oct 24 14:50:50 BST 2008

Kirk,

On Tue, Oct 21, 2008 at 5:40 PM, Kirk Wylie <kirk at kirkwylie.com> wrote:
> 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.

Don't get me wrong, the thing I that I would love the most is to be
proven wrong on this point.

The reason why I say this is because I have an interest in pushing
back the boundaries with Rabbit so I would quite humbly accept the
suggestion of an algorithm that allows you to match routes in
sublinear time over an arbitrarily large routing table whilst
deferring the specification of the algorithm to the bindings.

So if you really think that I do not possess the level of abstraction
required to think beyond the implementation I am currently working on,
please set me straight.

And lets set a few things straight, lest untruths manifest themselves
as technical arguments :-)

- Rabbit does not model every AMQP concept as a process - bindings or
routes are not modeled as processes;
- What do you mean excatly by "invoking a binding"?
- The routing table is dynamically modified by issuing the Bind and
Unbind commands to the broker.

Setting the rebuttal aside now to concentrate on the real design and
engineering concerns, do you think you can come up with a simple model
on paper for this?

Here's a suggestion of where one *may* start (requires a fixed width font):

                        -----------
                        | Message |
                        | key = x |
                        -----------
                             |
                             |
                        ------------
                        | Exchange |
                        | name = y |
                        ------------
                             |
        ------------------------------------------
        |                    |                   |
------------------  ------------------  ------------------
| Binding        |  | Binding        |  | Binding        |
| key = foo      |  | key = bar      |  | key = baz      |
| algorithm = A1 |  | algorithm = A2 |  | algorithm = A3 |
------------------  ------------------  ------------------

My point is that by deferring the algorithm to the bindings you are
removing any potential of using root metadata in when you compute the
routing graph.

Although this is slightly OT, this is reminiscent of the way that svn
stores metadata on a per-directory basis as opposed to storing it in
the root - the difference being the ease to which you can compute the
transitive closure of the graph.

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

You can currently use the passive flag to achieve this.

Ben