[rabbitmq-discuss] Drawbacks and advantages of "autoack" mode?
Alfonso Pantoja
I'm wondering which are the drawbacks/advantages of running a consumer
set to ack=true mode (so messages are ack'd when delivered to a
consumer) specially in critical systems where losing a message is not
an option.
Thank you in advance.
Regards,
Alfonso
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq...@lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Simon MacMullen
> I'm wondering which are the drawbacks/advantages of running a consumer
> set to ack=true mode (so messages are ack'd when delivered to a
> consumer)
Note: auto_ack = true really means no_ack = true, i.e. the broker will
consider the message acked as soon as it's gone to a consumer.
Advantages:
* It's faster
Drawbacks:
* If the client fails or the network goes down between the broker
sending the message and the consumer processing it (in some sense) then
the message will be lost.
> specially in critical systems where losing a message is not
> an option.
In this case, use explicit acks. No excuses :)
Cheers, Simon
--
Simon MacMullen
Staff Engineer, RabbitMQ
SpringSource, a division of VMware
Simon MacMullen
> On 14/04/11 10:45, Alfonso Pantoja wrote:
>> specially in critical systems where losing a message is not
>> an option.
>
> In this case, use explicit acks. No excuses :)
Actually, this could have been clearer, since it's often misunderstood.
The point of explicit ack-ing is not to prove that the message traversed
the network successfully. TCP does that for us. It's to prove that the
consuming application has taken responsibility for the message without
crashing - that it's made it into a database or a file, decided it can
safely ignore it, forwarded it to another system, whatever.
That's why it has to be an explicit step - only the consuming
application actually knows what constitutes accepting the message.
Alfonso Pantoja
On 14 abr, 11:57, Simon MacMullen <si...@rabbitmq.com> wrote:
>
> The point of explicit ack-ing is not to prove that the message traversed
> the network successfully. TCP does that for us. It's to prove that the
> consuming application has taken responsibility for the message without
> crashing - that it's made it into a database or a file, decided it can
> safely ignore it, forwarded it to another system, whatever.
>
> That's why it has to be an explicit step - only the consuming
> application actually knows what constitutes accepting the message.
Simon,
Reading your responses I'm wondering if
a queue consumed by a client using explicit-acking could contain
messages that had been requeued (i meant messages with Delivered flag
set to true)?
If yes, under which circumstances?
Regards,
Alfonso
Simon MacMullen
> Reading your responses I'm wondering if
> a queue consumed by a client using explicit-acking could contain
> messages that had been requeued (i meant messages with Delivered flag
> set to true)?
Yes, absolutely.
> If yes, under which circumstances?
If a message was delivered on a connection which then went down before
the message was acked.
Or someone used basic.reject(true) or basic.recover(true).
Cheers, Simon
--
Simon MacMullen
Staff Engineer, RabbitMQ
SpringSource, a division of VMware
_______________________________________________
Alfonso Pantoja
Sorry, my mistake. I meant "non explicit-
acking" (auto_ack=no_ack=true) instead of "explicit-acking".
So the question is if a queue consumed by a consumer using auto_ack
can contain messages with Delivered flag set to true?
Regards,
Alfonso
On 15 abr, 12:18, Simon MacMullen <si...@rabbitmq.com> wrote:
> On 15/04/11 00:10, Alfonso Pantoja wrote:
>
> > Reading your responses I'm wondering if
> > a queue consumed by a client using explicit-acking could contain
> > messages that had been requeued (i meant messages with Delivered flag
> > set to true)?
>
> Yes, absolutely.
>
> > If yes, under which circumstances?
>
> If a message was delivered on a connection which then went down before
> the message was acked.
>
> Or someone used basic.reject(true) or basic.recover(true).
>
> Cheers, Simon
>
> --
> Simon MacMullen
> Staff Engineer, RabbitMQ
> SpringSource, a division of VMware
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-disc...@lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Matthias Radestock
Alfonso Pantoja wrote:
> So the question is if a queue consumed by a consumer using auto_ack
> can contain messages with Delivered flag set to true?
Yes, it can. Specifically, when rabbit recovers from a non-clean
shutdown it may mark all messages as delivered since it has no way of
knowing for certain whether a message has been delivered. That way a
consumer can be sure that if the flag is not set then the message
definitely will not have been delivered before, which is the safer way
to deal with this uncertainty.
Regards,
Matthias.
Alfonso Pantoja
On 18 abr, 14:48, Matthias Radestock <matth...@rabbitmq.com> wrote:
> Yes, it can. Specifically, when rabbit recovers from a non-clean
> shutdown it may mark all messages as delivered since it has no way of
> knowing for certain whether a message has been delivered. That way a
> consumer can be sure that if the flag is not set then the message
> definitely will not have been delivered before, which is the safer way
> to deal with this uncertainty.
>
When consuming with auto_ack the acks are done by the consumer or
RabbitMQ automatically acks messages once delivered?
Matthias Radestock
Alfonso Pantoja wrote:
> When consuming with auto_ack the acks are done by the consumer or
> RabbitMQ automatically acks messages once delivered?
noack/auto-ack is a protocol feature. Hence it is implemented at the
server end, i.e. the server treats a message as ack'ed as soon as it
attempts to send it to a client which is basic.consume'ing/get'ing in
noack mode.
Regards,
Matthias.