[rabbitmq-discuss] Load balancing with multiple consumers on a single queue

Fri Aug 1 05:17:06 BST 2008

Hi all,

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.

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.

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

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?

Nathan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080801/daf493ce/attachment.htm 