https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32481 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (In reply to Julian Maurice from comment #6)
According to that tutorial, this allows RabbitMQ to redeliver the message to another worker. But do we really want that ?
Theoretically, yes. If you have multiple machines with workers running and 1 machine crashes due to a power outage, you probably want the message to be sent to a different worker on a different machine. A simpler scenario is RabbitMQ delivers a message, the worker is working on it, and a sysadmin reboots the server. When it comes back online, RabbitMQ and the worker should start up, and RabbitMQ should re-deliver the message to the worker.
A background job should not be restarted if it failed, because it might fail forever, or because by running it more than once it might do unwanted modifications to the database.
You make a good point about the failing forever. In practice, that seems to be the most common scenario I've encountered. The worker crashes due to a programming error, and then it is just stuck in an infinite failure loop. Not good. Of course, you could argue that isn't the problem of RabbitMQ, but rather someone coded the worker badly ;). Likewise, unwanted modifications to the database can be avoided by coding the worker better.
I believe that the background job worker should acknowledge the message as soon as it receives it.
That's certainly an option. The downside is that if the worker isn't able to complete handling of the message, then that message is gone forever. That might not be a big deal with Koha, since we have the "database fallback". Of course, that could get you into an infinite failure loop as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.