[Koha-bugs] [Bug 32573] background_jobs_worker.pl should ACK a message before it forks and runs the job

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Mon Jan 9 00:49:15 CET 2023


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32573

David Cook <dcook at prosentient.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcook at prosentient.com.au

--- Comment #3 from David Cook <dcook at prosentient.com.au> ---
I don't think there's 100% perfect answer for this topic.

If you look at "Message acknowledgement" on the following work queue tutorial,
it explicitly says that you should ACK after the work task has completed. It
does note how the 30 minute default timeout can be an issue.

https://www.rabbitmq.com/tutorials/tutorial-two-python.html

"Doing a task can take a few seconds, you may wonder what happens if a consumer
starts a long task and it terminates before it completes. With our current code
once RabbitMQ delivers message to the consumer, it immediately marks it for
deletion. In this case, if you terminate a worker, the message it was just
processing is lost. The messages that were dispatched to this particular worker
but were not yet handled are also lost.

But we don't want to lose any tasks. If a worker dies, we'd like the task to be
delivered to another worker.

In order to make sure a message is never lost, RabbitMQ supports message
acknowledgments. An ack(nowledgement) is sent back by the consumer to tell
RabbitMQ that a particular message had been received, processed and that
RabbitMQ is free to delete it.

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

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list