Grokbase › Groups › RabbitMQ › rabbitmq-discuss › October 2010
FAQ
Hi,

Is there any way to indicate that it is now safe tio delete the message from
RabbitMQ's queue ? any property ? or any flag or something like that ?

My use-case is that the message should be deleted from the queue only after
some processing is completed at the consumer's side.

Regards,
Kshitiz Garg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20101012/8f8524ec/attachment.htm>

Search Discussions

  • Matthew Sackman at Oct 12, 2010 at 1:47 pm ⇧

    On Tue, Oct 12, 2010 at 07:14:43PM +0530, Kshitiz Garg wrote:
    My use-case is that the message should be deleted from the queue only after
    some processing is completed at the consumer's side.
    Yes. Acknowledge the message after processing it. Thus consume or get
    the message with noAck = false.

    Matthew
  • Kshitiz Garg at Oct 12, 2010 at 6:17 pm ⇧
    Hi Mathhew/Simon,

    Thanks for your responses. I want to know that is the publisher is at all
    involved in the process when I consume with no_ack=false and then basic.ack
    messages after the processing ? I want to make sure that the publisher
    remains be free of any such impact.

    Regards,
    Kshitiz
    On Tue, Oct 12, 2010 at 7:17 PM, Matthew Sackman wrote:
    On Tue, Oct 12, 2010 at 07:14:43PM +0530, Kshitiz Garg wrote:
    My use-case is that the message should be deleted from the queue only after
    some processing is completed at the consumer's side.
    Yes. Acknowledge the message after processing it. Thus consume or get
    the message with noAck = false.

    Matthew
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20101012/1e3ddb91/attachment.htm>
  • Simon MacMullen at Oct 12, 2010 at 6:27 pm ⇧

    On 12/10/2010 7:17PM, Kshitiz Garg wrote:
    Thanks for your responses. I want to know that is the publisher is at
    all involved in the process when I consume with no_ack=false and then
    basic.ack messages after the processing ? I want to make sure that the
    publisher remains be free of any such impact.
    No, the publisher is not involved. If the consumer dies without acking a
    message then the message just goes back on the queue.

    Cheers, Simon
  • Kshitiz Garg at Oct 12, 2010 at 10:29 pm ⇧
    By the way, *noAck=false* seems to propose that I want an acknowledgment and
    not defer it...as *noAck=false* seems equivalent to *Ack=True* ?? please
    confirm ...
    On Tue, Oct 12, 2010 at 11:47 PM, Kshitiz Garg wrote:

    Hi Mathhew/Simon,

    Thanks for your responses. I want to know that is the publisher is at all
    involved in the process when I consume with no_ack=false and then basic.ack
    messages after the processing ? I want to make sure that the publisher
    remains be free of any such impact.

    Regards,
    Kshitiz

    On Tue, Oct 12, 2010 at 7:17 PM, Matthew Sackman wrote:
    On Tue, Oct 12, 2010 at 07:14:43PM +0530, Kshitiz Garg wrote:
    My use-case is that the message should be deleted from the queue only after
    some processing is completed at the consumer's side.
    Yes. Acknowledge the message after processing it. Thus consume or get
    the message with noAck = false.

    Matthew
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20101013/118144e4/attachment.htm>
  • Matthew Sackman at Oct 13, 2010 at 10:09 am ⇧

    On Wed, Oct 13, 2010 at 03:59:25AM +0530, Kshitiz Garg wrote:
    By the way, *noAck=false* seems to propose that I want an acknowledgment and
    not defer it...as *noAck=false* seems equivalent to *Ack=True* ?? please
    confirm ...
    You are correct: noAck=false <=> Ack=true
  • Irmo Manie at Oct 13, 2010 at 10:13 am ⇧
    Shouldn't that parameter be renamed anyway? In my opinion negative parameter
    names always cause to many confusions. 'autoAck' or something similar would
    be much better I reckon.

    /2cents
    Irmo
    On Wed, Oct 13, 2010 at 12:09 PM, Matthew Sackman wrote:
    On Wed, Oct 13, 2010 at 03:59:25AM +0530, Kshitiz Garg wrote:
    By the way, *noAck=false* seems to propose that I want an acknowledgment and
    not defer it...as *noAck=false* seems equivalent to *Ack=True* ?? please
    confirm ...
    You are correct: noAck=false <=> Ack=true
    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com
    https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20101013/db9ab13f/attachment.htm>
  • Matthew Sackman at Oct 13, 2010 at 10:17 am ⇧

    On Wed, Oct 13, 2010 at 12:13:06PM +0200, Irmo Manie wrote:
    Shouldn't that parameter be renamed anyway? In my opinion negative parameter
    names always cause to many confusions. 'autoAck' or something similar would
    be much better I reckon.
    Yup, and we do renaming as such within the codebase of the broker.
    Sadly, we can't unilaterally correct the AMQP spec.

    Matthew
  • Simon MacMullen at Oct 13, 2010 at 10:18 am ⇧

    On 13/10/10 11:13, Irmo Manie wrote:
    Shouldn't that parameter be renamed anyway? In my opinion negative
    parameter names always cause to many confusions. 'autoAck' or something
    similar would be much better I reckon.
    Maybe. It's part of the spec though. I'd be a bit reluctant to rename it
    in the clients since I think clients should use the same language as the
    spec, so we're all speaking the same language. And I guess maybe they
    named it like that in the spec since noAck=true is actually the
    non-typical way to do things, and they wanted booleans to default to
    false. At a guess.

    Cheers, Simon
    --
    Simon MacMullen
    Staff Engineer, RabbitMQ
    SpringSource, a division of VMware
  • Michael Bridgen at Oct 13, 2010 at 10:26 am ⇧

    On 10/13/2010 11:13 AM, Irmo Manie wrote:
    Shouldn't that parameter be renamed anyway? In my opinion negative
    parameter names always cause to many confusions. 'autoAck' or something
    similar would be much better I reckon.
    Renamed where? It's noAck in the AMQP protocol specification; so, it's
    a choice between faithfully reflecting the protocol or risking further
    confusion by reversing the negation. (To be fair, some client libraries
    actually do do this, and the sky doesn't fall)

    Probably better would be to avoid the double or triple negative by using
    an argument that isn't boolean, in APIs. For instance, "ack-mode" which
    can be "auto" or "client".

    mkb.
    /2cents
    Irmo

    On Wed, Oct 13, 2010 at 12:09 PM, Matthew Sackman <matthew at rabbitmq.com
    wrote:
    On Wed, Oct 13, 2010 at 03:59:25AM +0530, Kshitiz Garg wrote:
    By the way, *noAck=false* seems to propose that I want an
    acknowledgment and
    not defer it...as *noAck=false* seems equivalent to *Ack=True* ?? please
    confirm ...
    You are correct: noAck=false <=> Ack=true
    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com
    <mailto:rabbitmq-discuss at lists.rabbitmq.com>
    https://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
  • Simon MacMullen at Oct 13, 2010 at 10:15 am ⇧

    On 13/10/10 11:09, Matthew Sackman wrote:
    On Wed, Oct 13, 2010 at 03:59:25AM +0530, Kshitiz Garg wrote:
    By the way, *noAck=false* seems to propose that I want an acknowledgment and
    not defer it...as *noAck=false* seems equivalent to *Ack=True* ?? please
    confirm ...
    You are correct: noAck=false<=> Ack=true
    But just to be clear: noAck=false means "I intend to acknowledge
    messages myself after processing", which is not quite what Kshitiz seems
    to be saying with "not defer it".

    Cheers, Simon
    --
    Simon MacMullen
    Staff Engineer, RabbitMQ
    SpringSource, a division of VMware

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedOct 12, '10 at 1:44p
activeOct 13, '10 at 10:26a
posts11
users5
websiterabbitmq.com
irc#rabbitmq

5 users in discussion

Simon MacMullen: 3 posts Kshitiz Garg: 3 posts Matthew Sackman: 3 posts Irmo Manie: 1 post Michael Bridgen: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase