mirror of
https://github.com/odoo/runbot.git
synced 2025-03-19 09:25:46 +07:00
d4cb314e8f
The queueing system clearly tried to mitigate the time delay from the old cron style while trying to make things safe-ish. However this probably is unnecessary (and might be harmful) thanks to cron triggers: instead of processing a batch of records from the queue we can just process one record, then trigger the cron, until we don't find any record anymore. This means every cron run is much shorter (doesn't try to process 10~100 elements per loop) and should be way more reliable as they're all isolated, with some overhead to pay. A cron with a long queue also should not lock up a worker for quite as long. This means on server shutdown, the crons should just try to finish their current item (which hopefully doesn't take too long even for a multi-stage update) and once that's done allow for the cron worker to see the shutdown request. Also remove the mostly unnecessary exclusive lock on queue records: the cron system itself guarantees a given cron job only gets run by one worker at a time, so there should be no concurrent access to a job (except for trying to unlink a previously enqueued record I guess). Should limit the risks of #1085 repeating assuming it was caused by an abrupt termination after 90s. |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| forwardport.py | ||
| project_freeze.py | ||
| project.py | ||