[rabbitmq-discuss] SimpleRpcServer send generated queue name to client

Tue Mar 23 15:24:55 GMT 2010

Hi Glenn,

Ergeerts Glenn wrote:
> So this rules out client side filtering I guess?

Sounds like it, yeah.

> I did not know about the option of implementing a custom exchange type.. Is it hard to do?

No, it's now quite straightforward, though a bit bleeding-edge. The
required features have landed on default, meaning they're release-ready,
and will be in the next major release of rabbit.

> I don't know if this would be an ideal solution.. it feels strange pulling this application specific logic into the communication infrastructure (so tying our application to RabbitMQ) to me.. ?

I understand completely :-) It's a new kind of thing, I think, and
certainly a new way of thinking about networks---to have a programmable
network, how odd!---to me.

The question is *how much code* would you be embedding in the broker. If
it's not very much, then the amount you save by not having to
reimplement subscription management, expiry etc at the application level
perhaps outweighs the potential cost of migrating to another broker later.

> What would be the disadvantages of doing it with the multiple queues as first suggested? 
> Is it performance related? Would it make a big difference using a topic exchange compared to for example 20 queues + subscriptions?
> Are there other disadvantages?

It's not a performance issue: it's that you end up reimplementing
subscription and message distribution logic at the application level,
even though it is already available at the AMQP level. That's why it
makes sense to put the application logic *into* the AMQP level.

Tony