First of all, thanks for this plugin. Now I have a question.
Why do you acknowledge the message from the queue before the callback is concluded? By doing this way, the Round-Robin from Rabbit is always thinking a worker is free even it's not.
For my scenario, I have 3 or 4 processors (my name for a worker) and I can see that 1 or 2 are always more idle than others. I've tried to fine tune this by setting the prefetch configuration to 1, but this is useless.
As far I understand, by consuming a message will avoid other processor to read it, and the Rabbit documentation state that you can stay like this forever until ack or connection dies.
"If a consumer dies (its channel is closed, connection is closed, or TCP connection is lost) without sending an ack, RabbitMQ will understand that a message wasn't processed fully and will re-queue it. If there are other consumers online at the same time, it will then quickly redeliver it to another consumer. That way you can be sure that no message is lost, even if the workers occasionally die.
There aren't any message timeouts; RabbitMQ will redeliver the message when the consumer dies. It's fine even if processing a message takes a very, very long time."
So, as I don' t see the concerns why, I'm asking why have you choose this approach.
Hi!
First of all, thanks for this plugin. Now I have a question.
Why do you acknowledge the message from the queue before the callback is concluded? By doing this way, the Round-Robin from Rabbit is always thinking a worker is free even it's not.
For my scenario, I have 3 or 4 processors (my name for a worker) and I can see that 1 or 2 are always more idle than others. I've tried to fine tune this by setting the prefetch configuration to 1, but this is useless.
As far I understand, by consuming a message will avoid other processor to read it, and the Rabbit documentation state that you can stay like this forever until ack or connection dies.
From https://www.rabbitmq.com/tutorials/tutorial-two-javascript.html:
"If a consumer dies (its channel is closed, connection is closed, or TCP connection is lost) without sending an ack, RabbitMQ will understand that a message wasn't processed fully and will re-queue it. If there are other consumers online at the same time, it will then quickly redeliver it to another consumer. That way you can be sure that no message is lost, even if the workers occasionally die.
There aren't any message timeouts; RabbitMQ will redeliver the message when the consumer dies. It's fine even if processing a message takes a very, very long time."
So, as I don' t see the concerns why, I'm asking why have you choose this approach.
Thanks.