[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 16:28:55 CET 2023


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

Nick Clemens <nick at bywatersolutions.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick at bywatersolutions.com

--- Comment #7 from Nick Clemens <nick at bywatersolutions.com> ---
I think for Koha we should ack as soon as we receive the job from RabbitMQ

We maintain our own DB table for background jobs, and this is our source of
truth. We update this table with the results of a job, and use this table to
determine status.

If we maintained Rabbit as the source of truth, we might want to keep jobs
there until processed, but would then need to check Rabbit for the job statuses

Most of the jobs we are sending won't benefit from a retry if they fail - a bad
record won't index no matter how many times we try. If we have jobs that are
network based, and may fail because of connection issues, we should handle the
re-queuing in the job itself - so ack the job - try it, if fail then queue it
as new - then we can note the failure/requeue in Koha as well

It looks like the Stomp protocol recommendations differ from the Net::Stomp and
RabbitMQ docs, but I also don't see a negative side effect of ack before
process

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


More information about the Koha-bugs mailing list