[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
Tue Jan 10 00:28:30 CET 2023


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

--- Comment #10 from David Cook <dcook at prosentient.com.au> ---
But... as I note at
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27783#c64 my
libraries are not heavy users of background tasks at this point.

It sounds like Bywater are having the most struggles with the limitations of
current background job implementation, and probably with the batch record
modification?

With the current code, I can see how that could be a problem. It would probably
take quite a bit of re-engineering to break up a batch record modification into
chunks that could be easily digested. 

So I have a compromise...

Celery has an "acks_late" option for its tasks. Why don't we implement that
option on a per-task basis? 

For tasks that are idempotent, we can keep them with acks_late like we have
now. But for tasks that are more likely to run long (like the batch mods), then
we could ack early? That would be fairly trivial to code.

--

For ack early jobs, we could also have a cronjob that marks them as failed
after a configurable time (i.e. a time much longer than 30 minutes). Like
Minion's stuck_after: https://metacpan.org/pod/Minion#stuck_after

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


More information about the Koha-bugs mailing list