[rabbitmq-discuss] acks from temporary queues

Mon Sep 26 10:54:12 BST 2011

Hi Jonathan,

> 1. Do consumer acks have more significance in transactions, such that
> I could use those to effect the functionality I'm looking for?

Not really, no.  I don't think there's anyway to get what you want
automatically.

> 2. If not, is there any way (apart from the admin HTTP API) for
> determining the number of consumers (e.g., bound queues) for a given
> exchange? This way I could test the number of reply messages as you
> suggest; otherwise, with needing to register and account for a dynamic
> array of servers, I would lose a good deal of what I had hoped would
> be the benefit of a fanout broadcast.

There's no AMQP way of finding how many queues are bound to an exchange.
As you say, there's the management API, but using that is likely to lead
to races (what happens if you query the number of queues, then one of
the machines dies before it sends its acknowledgement?).

You could kind of get what you want with AMQP.  Use a fanout exchange
like you want for broadcast messages, but use a direct exchange for
direct communication between machines.  You could use the fanout
exchange to make sure that all the machines know about each other (in
particular, that each knows the queues the others bound to the direct
exchange, so that they can communicate directly).  And you could use the
direct exchange to publish persistent, confirm, mandatory, immediate messages
directly to other machines.  With these messages, the sender will be
notified if the other machine received the message (only a confirm is
received for the publish), or if the other machine went offline in the past
(a basic.return and a confirm is received).  This way, the sending
machine would know which other machines received its message and, so,
will know to wait for the correct number of responses.  The queue bound
to the direct exchange would have to be durable, auto-delete for this to
work (durable for confirms to work and auto-delete so that once the sole
consumer dies, the queue is deleted and publishing to it will result in
a basic.return).  In addition, when processing "please log out this
user" messages, a machine should *not* acknowledge that it has
received the message until after it publishes its response (this way, if
the machine dies while processing, the sender will get a basic.return for
it). 

Hope this helps.

Cheers,
Alex

On Fri, Sep 23, 2011 at 04:44:14PM -0700, gneeri wrote:
> Hi Matthias,
> 
> Thanks for clarifying that. From the explication of the rules for
> confirms, it had appeared to me that the relationships to queues and
> consumers had more weight in the confirmation process. That not being
> the case, I have 2 brief follow up questions:
> 
> 1. Do consumer acks have more significance in transactions, such that
> I could use those to effect the functionality I'm looking for?
> 
> 2. If not, is there any way (apart from the admin HTTP API) for
> determining the number of consumers (e.g., bound queues) for a given
> exchange? This way I could test the number of reply messages as you
> suggest; otherwise, with needing to register and account for a dynamic
> array of servers, I would lose a good deal of what I had hoped would
> be the benefit of a fanout broadcast.
> 
> Thanks in advance,
> Jonathan
> 
> On Sep 23, 6:55 pm, Matthias Radestock <matth... at rabbitmq.com> wrote:
> > On 23/09/11 21:26, gneeri wrote:
> >
> > > My expectation, then, is that producer would publish its message and
> > > then be blocked until the delayed consumer returns an ack
> >
> > Confirms mean one thing and one thing only: that the broker has accepted
> > responsibility for the message.
> >
> > They concern the interaction between producers and the broker, and  have
> > nothing to do with consumer acks.
> >
> > Yes, there are some conditions in which a consumer ack can trigger a
> > confirm in RabbitMQ, but that is an implementation detail and not
> > something you'd want to design an application around.
> >
> > > My hope is that I will not have to aggregate a list of servers and
> > > pass along a single message to each server, but perhaps that is what
> > > will be required.
> >
> > You can still send a single message via a fanout exchange. But the
> > consumers then in turn need to send a message back to the sender. Your
> > sender will need to know how many consumers there are so it knows when
> > it has gotten all responses..
> >
> > Regards,
> >
> > Matthias.
> > _______________________________________________
> > rabbitmq-discuss mailing list
> > rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss