This seems to work just fine, but I thought I'd ask just to be sure:
is it permitted to basicAck the same delivery tag more than once? It
does work, and the doc doesn't appear to say anything against it, but
I just don't want anything I'm doing to break in the future.

Search Discussions

  • Matthias Radestock at Jan 28, 2010 at 11:17 pm
    Tsuraan,

    tsuraan wrote:
    This seems to work just fine, but I thought I'd ask just to be sure:
    is it permitted to basicAck the same delivery tag more than once? It
    does work, and the doc doesn't appear to say anything against it, but
    I just don't want anything I'm doing to break in the future.
    Actually, the 0-9-1 spec makes it clear that a client must not ack a
    message more than once. RabbitMQ, as you observed, currently doesn't
    care, but that may well change.


    Regards,

    Matthias.
  • Tsuraan at Jan 29, 2010 at 4:12 am

    Actually, the 0-9-1 spec makes it clear that a client must not ack a
    message more than once. RabbitMQ, as you observed, currently doesn't
    care, but that may well change.
    Is that to allow a single channel to reuse dtags? I would think the
    behaviour of multi-ack would make that impossible anyhow.
  • Matthias Radestock at Jan 29, 2010 at 8:07 am
    Tsuraan,

    tsuraan wrote:
    Actually, the 0-9-1 spec makes it clear that a client must not ack a
    message more than once. RabbitMQ, as you observed, currently doesn't
    care, but that may well change.
    Is that to allow a single channel to reuse dtags?
    No. Given that the transport is reliable, there is no good reason for a
    client to issue the same ack more than once. If it does then that
    probably indicates a bug in the client code. So with the restriction in
    place the server can tell the client that it's probably doing something
    wrong.


    Regards,

    Matthias.
  • Tsuraan at Jan 29, 2010 at 3:51 pm

    No. Given that the transport is reliable, there is no good reason for a
    client to issue the same ack more than once. If it does then that
    probably indicates a bug in the client code. So with the restriction in
    place the server can tell the client that it's probably doing something
    wrong.
    Well, maybe it's a little wrong :) The messages in my system are
    handled asynchronously, and once the work associated with some number
    of messages is done, I want to ack them. I can't use the rabbit
    channel from the thread that does the processing, so I have a
    workaround that has a possiblity of multiple acks on the same tag.
    I'm guessing I can come up with a cleaner solution though. I suppose
    maybe the cleanest way to handle this would be to wrap
    QueueingConsumer in a class that mantains a list of dtags that need
    acking, so whenever the consumer gets a message (or times out) it acks
    the messages at once. I think I'll do it that way; it seems a lot
    cleaner that what I'm doing now.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedJan 28, '10 at 11:01p
activeJan 29, '10 at 3:51p
posts5
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Tsuraan: 3 posts Matthias Radestock: 2 posts

People

Translate

site design / logo © 2022 Grokbase