[rabbitmq-discuss] Exchanges, Routing, and AMQP

Sat Oct 25 13:11:37 BST 2008

Matthias (and BTW, I think I messed up your name on a blog post; for
that I apologize).

On Fri, Oct 24, 2008 at 2:01 PM, Matthias Radestock <matthias at lshift.net> wrote:
>>> 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.
>
> Would your proposed model allow for routing decisions that are based on the
> set of all bindings (or some subset thereof), rather than each individual
> binding? Ben's example - an exchange that routes to the shorted queue -
> requires the former.

It would depend on the server-side implementation as to whether that
was possible, since custom routing rules are outside the scope of the
protocol itself.

My suspicion is that any reasonable implementation allowing for
optimized performance would require the same hooks necessary to
implement shortest-queue-routing. This is because you'd have to have a
compilation step once the binding is declared before you could use it
(so that you're not just reparsing text all the time if nothing else).
In the context state where you're storing the pre-compiled binding
rule, you could be able to store data necessary for the shortest-queue
routing rule.

But it's really an implementation detail to be honest. I could easily
see an implementation which forces routing rules into such a localized
decision that you couldn't do that type of global routing logic, and
in a lot of cases that would in fact be easier to keep highly
performant.

Kirk