Sim
Well-known member
- Affected version
- 2.2b1
The current logic for the
Given the
Indeed, if for some reason the rate of new jobs being spawned is greater than the rate at which we can process them - this command may never actually end!
I strongly recommend that the command be allowed to run for no longer than 1 minute (or perhaps even 30 seconds in case the last job takes longer than expected).
Perhaps something like:
... or make that 30 second limit configurable.
xf:run-jobs command may in some circumstances see the task never stop - or at least run for longer than the server cron period.
PHP:
do
{
$jobManager->runQueue($manualOnly, $maxRunTime);
// keep the memory limit down on long running jobs
$app->em()->clearEntityCache();
// IF WE HAVE MORE JOBS IN THE QUEUE, KEEP EXECUTING
// REGARDLESS OF HOW LONG WE'VE ALREADY BEEN RUNNING
$more = $jobManager->queuePending($manualOnly);
if (!$more)
{
break;
}
}
while (true);Given the
run-jobs command is designed to be executed once per minute by a server cron task - if we have a large number of outstanding jobs to process, it could conceivably take longer than 1 minute to clear the queue - thus causing a situation where we have multiple run-jobs commands executing at the same time.Indeed, if for some reason the rate of new jobs being spawned is greater than the rate at which we can process them - this command may never actually end!
I strongly recommend that the command be allowed to run for no longer than 1 minute (or perhaps even 30 seconds in case the last job takes longer than expected).
Perhaps something like:
PHP:
$start = microtime(true);
do
{
$jobManager->runQueue($manualOnly, $maxRunTime);
// keep the memory limit down on long running jobs
$app->em()->clearEntityCache();
$more = $jobManager->queuePending($manualOnly);
if (!$more)
{
break;
}
}
while (microtime(true) - $start < 30); // STOP AFTER 30 SECONDS AND WAIT FOR NEXT CRON TRIGGER... or make that 30 second limit configurable.
Last edited:
