[rabbitmq-discuss] Exchanges, Routing, and AMQP

[Edwin Fine]

Ben, Thanks.

Coincidentally, I did look into rabbit_exchange:route while waiting for your
response. One (very very minor) thing that struck me on reading it was the
use of regexp:split/2 to convert "a.dotted.topic.key" to
["a","dotted","topic","key"]. I wondered why the more efficient
string:tokens/2 was not used. They do have different behavior in edge
conditions (e.g. ".atopic") - was that the reason?

Anyway, besides that, for now I'll probably just go with a topic exchange,
which seems to be the general purpose ancestor of all the others. I really
do not want to add my code to the Rabbit server side and risk having merge
difficulties when future releases arise...

Regards,
Edwin

On Mon, Oct 20, 2008 at 8:50 PM, Ben Hood <0x6e6562 at gmail.com> wrote:

> Edwin,
>
> On Mon, Oct 20, 2008 at 11:17 PM, Edwin Fine
> <rabbitmq-discuss_efine at usa.net> wrote:
> > Sorry if this is answered elsewhere (I did look), but how (in a nutshell)
> > would I implement my own custom exchange type?
>
> 1. The abridged version:
>
> If you look into at functions rabbit_exchange:route/2 and
> lookup_qpids:/1 in the same module on the 18776 branch, you might be
> able to follow how the generalized routing mechanism works. Basically
> you read the routing table for bindings to queue names that match your
> key, resolve their corresponding process ids and the rest is handled
> for you.
>
> 2. The realistic version:
>
> Somehow you're going to have to make a routing decision, and this
> usually has something to do with bindings, although you could
> theoretically create some kind of foo exchange that just picks some
> queue names out of a hat. But if you need to do stateful routing,
> you're going to have to retrieve the state from somewhere.
>
> You might also want to make sure that you are not breaking any other
> functionality that you currently rely on when you do this.
>
> This also wouldn't necessarily been spec compliant per se, although
> section 3.1.3.6 of the 0-9 spec mentions the possibility of custom
> exchanges. So you would have to be comfortable with that.
>
> And, unless it was a really worthwhile addition, we probably wouldn't
> maintain it in the main Rabbit tree.
>
> Other than that, feel free to do so. We have talked about plugable
> queues before (although Matthias has rightly pointed out that this is
> much easier said than done) so why should exchanges be any different?
>
> But despite all of these practical considerations, there is a lot of
> merit to adding custom exchanges (which Kirk may interpret as custom
> routing algorithms :-), because the exchange is point in the AMQP
> pipeline with the greatest amount of leverage effect when it comes
> down to deciding which messages go where.
>
> HTH,
>
> Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081021/2f4c9bc1/attachment.htm