[Koha-bugs] [Bug 32481] Rabbit times out when too many jobs are queued and the response takes too long

[bugzilla-daemon at bugs.koha-community.org]

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

--- Comment #9 from David Cook <dcook at 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.