[rabbitmq-discuss] acks from temporary queues

[Alexandru Scvorţov]

Hi Jonathan,

> I apologize if this is an ill-informed question: In a nutshell, the
> thing I am trying to accomplish is blocking a producer until it has
> received acks (or even nacks) from all consumers on temporary queues
> bound to a given (fanout) exchange for a single message. From the
> docs, my sense is that using confirms and waitForConfirms would be
> preferable to full on transactions,

Confirms are usually the way to go.

With confirms enabled, calling waitForConfirms would block the producer
until all published messages on that channel are acknowledged *by the
broker*.  The broker, in turn, will only acknowledge the message if 1)
it has been persisted to disk; *or* if 2) it has been delivered to a
consumer on each of the queues it had reached.

You can't really specify that you only want the acknowledgement if the
messages are delivered and not if they're persisted.

Also, you said "temporary queues".  Confirms will only work as described
above if the message is persistent and if the queues it lands on are
durable.  A message that lands on a non-durable queue is considered
acknowledged on that queue immediately (of course, the broker will still
wait for it to be persisted or acknowledged on all the other queues it
reached, before acknowledging it to the producer).

> but as each instance of the
> producer will be on its own thread,

That's fine.  Just make sure to use a separate channel for each
producer (calling waitForConfirms on the same channel from multiple
threads will almost certainly not do what you want it to).

> The main point of confusion for me here is whether I can get multiple
> acks (from all consumers) for one message without having any prior
> information about the number of queues attached to the exchange. That
> is, I don't just want to know that one queue has received the message,
> but that all queues bound to the exchange have done so. It seems clear

Not quite sure what you mean.  A published message, even if it gets sent
to multiple queues, is still *one* message with a certain sequence
number.  A published message will be acknowledged by the broker only
once, when it has been written to disk or when it has been successfully
sent to a consumer from each queue.

Consumer acks and publisher acks are completely different things.  A
consumer acks a message to tell *the broker* (not the publisher) that it
has taken responsibility for the message (by using it up, by forwarding
it, by doing something with it).  The broker acks a message to tell *the
publisher* that it has taken responsibility for the message (by saving
it to disk, or by handing it over to consumers).

When a message reaches a queue, and is then delivered to a consumer, the
broker will consider the message delivered only when the consumer
acknowledges it.  So, if it weren't for the "writing the message to
disk" part, it would work exactly the way you're expecting it to.

What sort of system are you designing?

Hope this helps.

Cheers,
Alex


On Thu, Sep 22, 2011 at 12:22:50PM -0700, gneeri wrote:
> I apologize if this is an ill-informed question: In a nutshell, the
> thing I am trying to accomplish is blocking a producer until it has
> received acks (or even nacks) from all consumers on temporary queues
> bound to a given (fanout) exchange for a single message. From the
> docs, my sense is that using confirms and waitForConfirms would be
> preferable to full on transactions, but as each instance of the
> producer will be on its own thread, I am open to using transactions.
> The main point of confusion for me here is whether I can get multiple
> acks (from all consumers) for one message without having any prior
> information about the number of queues attached to the exchange. That
> is, I don't just want to know that one queue has received the message,
> but that all queues bound to the exchange have done so. It seems clear
> that if I send one message per attached queue, I could create a set of
> seqNos and check against that to verify acks for all of the messages,
> but without a list of bound queues (which I cannot see how to get),
> that does not seem like an option. In any case, it seems likely that
> there is something that I am missing here. That said, I would
> appreciate any thoughts (or even clarifying questions) on this.
> 
> Thanks,
> Jonathan
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss