[rabbitmq-discuss] opposite of basicAck?

[Valentino Volonghi]

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