[rabbitmq-discuss] question on exchange type

[Ben Hood]

Mark,

On Mon, Feb 2, 2009 at 8:58 PM, Mark Geib <mark.geib at echostar.com> wrote:
> Is there an exchange that will 'queue' messages, backed by disk, until a
> queue binding appears where the messages would be routed. That is,
> messages that are excepted by an exchange are NEVER dropped. If there is
> no existing route for a message then queue it for later. Then when ever
> a new binding is created check all the queued messages if they can be
> routed.

No, there isn't an exchange type that will do this OOTB.

However, there are some building blocks that will let you achieve this
behavior yourself:

- Setting the persistent flag when you send messages;
- Declaring your own queue to catch all messages;
- Marking exchanges/queues as durable (note the difference to
persistent messages);

Having said that, these may not be as good as a custom exchange
solution for your particular problem, which is going to depend on your
actual use case.

Coincidentally I find this an interesting question because it touches
on a number of cross cutting concerns that are currently being
discussed on the list in various threads:

- Last value caching on a per exchange/routing key basis - this has
some similarities with what (I think) you're trying to achieve -
please read the relevant thread for the background;
- Whether or not AMQP events should be published so that application
code can subscribe and implement custom behavior (reminiscent of a
micro-kernel architecture);
- The age old question of why persistence is defined on a per-message
basis as opposed to a per-queue basis (this is more of a protocol
revision question - the implementors of other AMQP brokers may have
something to say about this);

Having said this, there are a few more general questions you might to
address, which will be influenced by your actual requirements:

- The resource consumption aspect of saving *everything*, including
stuff that nobody cares about - which ties into the next point;
- In general, the flavor of AMQP is consumer-driven messaging, i.e. if
you care about something, you'll take the necessary steps to get that
something - part of your suggestion contradicts this principle to an
extent - whether or not that is bad is up to interpretation;

Hopefully this can serve as a starting point for a discussion,

Ben