Since 8.1 Cron::processQueues() does this:
$lease_time = isset($info['cron']['time']) ? : NULL;
setting lease_time to the maximum time new queue jobs may be executed.
Before it was the default 1 hour for claimItem.
Now, we do have a queue (cron is called every 5 minutes) where one task could take a little more than 5 minutes (downloading a large file). But most tasks are shorter, to be save, I set the queue time to 50 seconds (I don't want to start a queue item after that time).
What now happens is: processQueues sets the lease to time+50 sec, the task works for more than 5 minutes, the next cron call arrives before, finds lease has expired, and calls the same item again, again taking 5 minutes.
Suggestion: leave lease_time at 1 hour or add another optional annotation.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | core_cron-lease-time_2833657-12_D8.patch | 751 bytes | rkostov |
| #6 | cron_uses_max_time_as_lease_time.patch | 751 bytes | tuneke |
Comments
Comment #3
dropa commentedActually, the
$lease_timeis eitherTRUEorNULL, which is a bug in my eyes. So I believe you haven't ever even gotten the +50seconds to the lease time.Comment #6
tuneke commentedHere is a patch to actually use the maximum time new queue jobs may be executed as lease time.
Comment #8
nuezComment #9
nuezComment #10
nuezThis issue is closely related to
Comment #11
rlmumfordI'm reopening this, as the supposed duplicate makes a large API change that will take a long time to be accepted and this issue is a major bug. The patch in #6 resolves the immediate issue.
Comment #12
rkostov commentedIn case anyone needs it, a reroll for the 8.9.x branch.
Comment #13
rlmumfordComment #14
pfrenssenThanks for the reroll!
I agree with @nuez however that this issue is a duplicate of #2893933: claimItem in the database and memory queues does not use expire correctly. This one is not so close to being committed as it may seem, since it lacks test coverage. The other issue has tests to prove that the bug is conclusively fixed, so it is further ahead in the race to be included in core.
I agree that the scope of this is narrower than the other issue, but still I would propose to focus efforts in reviewing that issue instead of spending the effort to duplicate the tests in this issue. It would just introduce a merge conflict that adds again more work.