If I have a message that I know that I don't want to handle right now,
is there something like basicAck that rejects a deliveryTag instead of
acking it? IIRC, after some timeout, or a channel close, the message
will be queued for redelivery, but I have a case where I know that a
message I received isn't useful for me yet, so I'd like to immediately
reject it so I can pick it up later. Is that possible?

Search Discussions

  • Valentino Volonghi at Jun 25, 2009 at 7:20 pm

    On Jun 25, 2009, at 9:57 AM, tsuraan wrote:

    If I have a message that I know that I don't want to handle right now,
    is there something like basicAck that rejects a deliveryTag instead of
    acking it? IIRC, after some timeout, or a channel close, the message
    will be queued for redelivery, but I have a case where I know that a
    message I received isn't useful for me yet, so I'd like to immediately
    reject it so I can pick it up later. Is that possible?

    Not really I suppose. Unless some exchange is created that delivers
    messages in a future date.

    This incidentally is a problem that I'm dealing with in quebert.

    http://bitbucket.org/adroll/quebert/src/tip/quebert/amqp.py#cl-140

    There are a bunch of ways in which you could try to deal with the
    problem,
    and I still haven't figured out which one is the best one... But
    essentially
    you could (with your wanted variations):

    If there is a prefetch count set to X:
    Option A:
    - Only after an exception raise X to X+1
    - Backoff an arbitrary delay (exponentially or fixed)
    - call basic_recover (with requeue=True if you want it
    redelivered
    potentially to any queue)
    - decrease X+1 back to X

    Option B:
    - After "timeout" time passed raise X to X+1
    - When the message that is taking the timeout has finished
    waiting call basic_recover (same options as above)
    - decrease X+1 to X

    If there's no prefetch simply hold the message unackd for your preferred
    delay.

    Currently in quebert I implemented option B. But that's suboptimal for
    tasks that actually take long because they are heavy and increasing
    the number of prefetches might not be good because with few machines
    it might end up clogging those few workers and grow indefinitely (if all
    tasks in the worst case go to timeout).

    If I can find a clean way in my code to implement Option A I would go
    for
    it... But a simple exception might not be good enough... I dunno, plus
    it's
    hard to keep the "event handler" fully separated from amqp when, in
    order
    to increase/decrease the prefetch window it needs access to the
    channel...

    Agh... My head is already hurting...

    --
    Valentino Volonghi aka Dialtone
    Now running MacOS X 10.5
    Home Page: http://www.twisted.it
    http://www.adroll.com

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: PGP.sig
    Type: application/pgp-signature
    Size: 194 bytes
    Desc: This is a digitally signed message part
    Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090625/2efa48a1/attachment.pgp
  • Ben Hood at Jul 15, 2009 at 10:57 pm
    Tsuraan,

    On Thu, Jun 25, 2009 at 5:57 PM, tsuraanwrote:
    If I have a message that I know that I don't want to handle right now,
    is there something like basicAck that rejects a deliveryTag instead of
    acking it? ?IIRC, after some timeout, or a channel close, the message
    will be queued for redelivery, but I have a case where I know that a
    message I received isn't useful for me yet, so I'd like to immediately
    reject it so I can pick it up later. ?Is that possible?
    0-8 rejections, were Rabbit to implement them, are scoped on a
    channel. Just nuking the channel and letting them get consumed on a
    different channel has the same effect.

    Ben
  • Amit bhatnagar at Jul 16, 2009 at 2:22 pm
    When you do this by closing the channel, (essentially faking a
    Basic.Reject), the message gets put back on the queue and gets ready
    for consumption by another consumer (or channel from same consumer if
    it had more than one channel).

    a) Is the producer registering for an BasicReturn listener the proper
    mechanism to be informed that the message was undeliverable?

    b) If a is true, how long would the message sit on the queue waiting
    for a potential consumer to pick it up before the basic.return was
    generated by the broker back for the producer?

    c) If no such BasicReturn listener was registered, the message gets
    dropped?
    On Jul 15, 4:57?pm, Ben Hood wrote:
    0-8 rejections, were Rabbit to implement them, are scoped on a
    channel. Just nuking the channel and letting them get consumed on a
    different channel has the same effect.

    Ben

    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-disc... at lists.rabbitmq.comhttp://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
  • Ben Hood at Jul 16, 2009 at 5:27 pm
    Amit,

    On Thu, Jul 16, 2009 at 3:22 PM, amit bhatnagarwrote:
    When you do this by closing the channel, (essentially faking a
    Basic.Reject), the message gets put back on the queue and gets ready
    for consumption by another consumer (or channel from same consumer if
    it had more than one channel).

    a) Is the producer registering for an BasicReturn listener the proper
    mechanism to be informed that the message was undeliverable?
    The answer to your question might lie in the spec's definition of the
    BasicReturn command:

    "This method returns an undeliverable message that was published with
    the "immediate" flag set, or an unroutable message published with the
    "mandatory" flag set. The reply code and text provide information
    about the reason that the message was undeliverable."

    b) If a is true, how long would the message sit on the queue waiting
    for a potential consumer to pick it up before the basic.return was
    generated by the broker back for the producer?
    See above.
    c) If no such BasicReturn listener was registered, the message gets
    dropped?
    The broker will send the rejection back to the client in any case.
    Whether this ever lands back in the client application depends on
    whether (a) the client library black holes these messages or (b)
    whether the client application registers some kind of callback to
    handle returns. Both of which are outside of the broker's remit.

    Ben

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedJun 25, '09 at 4:57p
activeJul 16, '09 at 5:27p
posts5
users4
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase