<div dir="ltr">Hi all,<br><br>Alexis: although your solution isn't ideal, the amount of processing a task requires is roughly related to the size so that might be a good option. Where can I find the options for doing the advanced routing rules? So far I've only seen routing based on the routing_key property.<br>
<br>Re: Basic reject, it appears to be implemented in the library I'm using and I've done some initial tests in which the reject seems to work right up until the last message where I get the following back from the server: (503, u'COMMAND_INVALID', (60, 90), 'Channel.basic_reject'). I'll have to test/look into this more, it could just be a library issue. However, we would then have to make our clients multi-threaded, one thread to reject the new messages as they come in and another to deal with the current job. This is a viable solution but not a great one, hoping to use the cancel instead.<br>
<br>Finally, after my initial tests the consume, ack message, cancel, deal with message, send response, re-consume system worked perfectly, until I upped the message throughput and the client library gets a basic_deliver instead of the basic_cancel_ok it expected. I edited the library to not error in this instance and to ignore messages after the cancel had been sent however when I start the consume again I have a client waiting for a message to finish getting delivered it seems which never happens. Tonyg (on irc) said for the cancel to work properly I'd probably have to cancel the channel/connection rather than just doing a basic_cancel. Which I've tried with limited success (it appears to work, however I'm running into the unexpected response issue again so I'll have to check the client code).<br>
<br>I might give "recover" a test. At first glance it looks like I should run it after I've ack'd the message I'm about to process and issued the cancel?<br><br>Nathan.<br></div>