[rabbitmq-discuss] opposite of basicAck?

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...

Tsuraan,

On Thu, Jun 25, 2009 at 5:57 PM, tsuraanwrote:
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

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?

Amit,

On Thu, Jul 16, 2009 at 3:22 PM, amit bhatnagarwrote:
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."

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