Hi,

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

Search Discussions

  • Simon MacMullen at Apr 14, 2011 at 9:49 am

    On 14/04/11 10:45, Alfonso Pantoja wrote:
    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 at Apr 14, 2011 at 9:57 am

    On 14/04/11 10:49, Simon MacMullen wrote:
    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.

    Cheers, Simon

    --
    Simon MacMullen
    Staff Engineer, RabbitMQ
    SpringSource, a division of VMware
  • Alfonso Pantoja at Apr 14, 2011 at 11:10 pm

    On 14 abr, 11:57, Simon MacMullen 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 at Apr 15, 2011 at 10:18 am

    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
  • Alfonso Pantoja at Apr 18, 2011 at 8:23 am
    Simon,

    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 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... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
  • Matthias Radestock at Apr 18, 2011 at 12:48 pm
    Alfonso,

    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 at Apr 18, 2011 at 4:24 pm

    On 18 abr, 14:48, Matthias Radestock 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 at Apr 18, 2011 at 6:28 pm
    Alfonso,

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedApr 14, '11 at 9:45a
activeApr 18, '11 at 6:28p
posts9
users3
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase