[rabbitmq-discuss] Examining Queue Failover Behavior

[Jason J. W. Williams]

>
> 1. Specifying persistence as a message level attribute is
> questionable. There is a school of thought that says this this should
> an attribute of a queue. This would be a discussion for either
> evolving the spec or looking into whether a broker could handle this
> as a QOS feature.

Well, my only argument would be that a persistent queue doesn't
guarantee a whole lot if the message never makes it there. The problem
it seems to me depends on the application. If the producer has
pre-knowledge that the message its entrusting to the MQ is important,
it needs to be able top specify a level of persistence in case the MQ
crashes before the exchange can route it. Beyond that, I think its up
to the consumer to make sure here's a queue available for the message.
But in a failure environment, since exchanges fail over, but queues do
not, you now have an issue where producers may publish messages before
consumers can re-attach and recreate the queues. Where as initially,
neither the exchanges nor the queues would exist until the consumers
created them, thereby preventing the producers from publishing into
ether. As I write this out, it now strikes me that that is the crux of
our issue: Exchange metadata fails over automatically but not queues.


Regarding RAS, RAS = Reliability, Availability, Serviceability:
http://en.wikipedia.org/wiki/Reliability,_Availability_and_Serviceability

-J