https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32573
Nick Clemens <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #7 from Nick Clemens <[email protected]> --- 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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
