[rabbitmq-discuss] question on exchange type

[Mark Geib]

Ben,

Thanks for the reply and suggestions. I will look at the list threads.

The system I am building is, from the amqp broker point of view at 
least, very producer oriented for sure. What is vital is that a producer 
can safely hand off a message to the broker, knowing that at some time a 
consumer will get it. That is, once the message is published the 
responsibility of that message is moved to the broker...even if no 
consumer currently exists. The issue I am struggling with is that if I 
have to create and bind a queue in the producer to make this happen then 
I have already routed the message. This eliminates what consumers can do 
in the way of 'subscribing' to exchanges to have messages routed to it.

Mark.

Ben Hood wrote:
> 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
> 

-- 
Principal Engineer
Cheyenne Software Engineering
mark.geib at echostar.com / 35-215