[rabbitmq-discuss] Persistent messages and durable queue questions

[Elias Levy]

On Wed, Jun 22, 2011 at 1:15 AM, Rob Harrop <rob at rabbitmq.com> wrote:

>
> When there is a consumer ready to receive the message, the message will
> only be written to disk if:
>
> 1. The queue is durable
> 2. The message is peristent
> 3. Automatic ack is disabled


Rob,

Thanks for your response.  I was afraid that might be the case.  That said,
I've read with interest the discussion on the upcoming HA queue feature.
 It's exactly what we are looking for.  Hopefully it will be release in not
too long a time.


> You can use publisher confirms to allow your application code to know when
> a message has successfully been routed or when it has been lost.
>
> See: http://www.rabbitmq.com/**extensions.html#confirms<http://www.rabbitmq.com/extensions.html#confirms>


Alas, I believe, publisher confirms do not solve the problem. As I stated, I
expect only a subset of the messages published to the topic exchange to have
matching bindings.  Most messages will not be routed anywhere.  Publisher
confirms will return basic.ack for such messages.  That is all well and good
under normal conditions.

But if there is a node with a queue with a binding that matches the message,
and that node goes down, then it is my understanding that the rest of the
cluster will discard the binding since the queue is no longer reachable.  If
that is the case, then publisher confirms will return a basic.ack rather
than a basic.nack.  Thus the publisher will not know that there was a queue
with a binding that matched the message, but its just not available at this
time.

Is my understanding incorrect?

This becomes less of an issue once the HA queues feature is shipped, as I
configure the cluster the deliver the message to a queue even in the face a
configurable number of nodes being down.

Elias Levy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110624/7f65acee/attachment-0001.htm>