<div dir="ltr">Hmmm - I use pika a lot and have occasion to use channel.basic_nack. It takes about 5 ms before the message is picked up by another consumer in my case.<div><br></div><div>If you are using BlockingConnection, I would suggest testing instead with one of the asynch adapters, e.g. SelectConnection. Or use TornadoConnection if you need more speed/responsiveness, or LibevConnection (which I wrote and is in a pull request at the pika project github) if you are adventurous and want "the one that rules them all" (for python anyway).</div>
<div><br></div><div>There's really no good reason for the delays you are experiencing. </div><div><br></div><div>AFIK, however, the rejected/nacked messages is queued as if it were new, but with the redeliver flag set, AND any consumer may receive them, including the one which rejected/nacked them. Of course if you have multiple consumers on a queue, the rabbit will round-robin.</div>
<div><br></div><div>But, the rejected/nacked message does not go to the 'front' of the queue as you desired (again AFAIK).</div><div><br></div><div>At the platitude level, I would suggest that you 'think async' - because the real world, and rabbitmq, work that way. Avoid anything with 'blocking' in it.</div>
<div><br></div><div>Michael Laing</div><div>NYTimes</div></div>