<div dir="ltr">Hi all,<br><br>Alexis: although your solution isn&#39;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&#39;ve only seen routing based on the routing_key property.<br>
<br>Re: Basic reject, it appears to be implemented in the library I&#39;m using and I&#39;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&#39;COMMAND_INVALID&#39;, (60, 90), &#39;Channel.basic_reject&#39;). I&#39;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&#39;d probably have to cancel the channel/connection rather than just doing a basic_cancel. Which I&#39;ve tried with limited success (it appears to work, however I&#39;m running into the unexpected response issue again so I&#39;ll have to check the client code).<br>
<br>I might give &quot;recover&quot; a test. At first glance it looks like I should run it after I&#39;ve ack&#39;d the message I&#39;m about to process and issued the cancel?<br><br>Nathan.<br></div>