Allow run() to be executed multiple times #24
Conversation
The current code expects the run() to be called only once. This is fine if you start the scheduler from cron each minute and re-initialize it each time. If you want to manually run the scheduler, or maybe have a lot of jobs you do not want to init each minute, it would be useful to call run() multiple times in the lifetime of the scheduler. In this case the collected data of the last run should be reset. the executedJobs, failedJobs and outputSchedule.
If the scheduler is used to do multiple runs then it would be useful to reset all queued Jobs. Currently the only way to do this is by re-creating the scheduler object. But if the object is injected in the code then this is not practical..
Comment format fixed.
|
The PHP 7.1 Travis build seems to fail randomly 2-3 tests. The tests seem to be related to async_job.php and a test involving a sleep. My local PHP 7.1 test ran just fine: |
|
Hi @merijnvdk thank you for your PR, I know about the issue with travis-ci (it happened with another PR, not sure why though, in my local those tests are running just fine). Can you please provide a use case for this PR? Just as a reminder, the scheduler is meant to run as a cronjob, jobs should be executed only if due to run on that particular timeframe. Maybe there should be another function to manually trigger a fresh run? To give you an example $scheduler->php('myscript.php');
$scheduler->run(); // myscript.php runs, the scheduler executed 1 job
// ...
$scheduler->php('my_other_script.php');
// ...
// both myscript.php and my_other_script.php are running now,
// the scheduler executed a total of 3 jobs since it started
$scheduler->run();A different implementation of your PR could be $scheduler->php('myscript.php');
$scheduler->run(); // myscript.php runs, the scheduler executed 1 job
$scheduler->run(); // myscript.php runs again, the scheduler executed a total of 2 jobs
// here you are actively saying you want a fresh run
// inside this function you can reset the arrays
$scheduler->freshRun();Another possible implementation could be $scheduler->php('myscript.php');
$scheduler->run();
// Actively reset the scheduler
// this will clear the queued jobs and everything else
$scheduler->reset();
$scheduler->php('my_other_script.php');
// In this case there is no need to have a "freshRun" method
$scheduler->run();I think the correct implementation depends on a real use case. Another possible implementation would be to have multiple scheduler instances. $easyJobs = [
'myscript.php',
....
];
$heavyJobs = [
'my_other_script.php',
....
];
$config = [...];
$schedulerEasyJobs = new Scheduler($config);
$schedulerHeavyJobs = new Scheduler($config);
foreach ($easyJobs as $job) {
$schedulerEasyJobs->php($job);
}
$schedulerEasyJobs->run();
// ...
foreach ($heavyJobs as $job) {
$schedulerHeavyJobs->php($job);
}
$schedulerHeavyJobs->run();
// ... at the end of your script you can call your log function
logSchedulerReports([$schedulerEasyJobs, $schedulerHeavyJobs]);Again, a real use case would help choose the correct implementation for this feature. |
|
While I think most people would handle the results for each run, the freshRun() solution would at least be fully backwards compatible and the most flexible solution. But it is a bit counter intuitive that run() returns a cummulative result instead of the executed jobs for that particular run. I would not add a full reset() method because clearing the jobs and clearing the run() result are two different things. But a resetRun() would be ok too. My use case is running the scheduler every minute from a daemon. And only re-adding all jobs (from external source) when they have changed (in that external source). So the scheduler has a long lifetime. |
After discussion with @peppeocchi make the re-running manually triggered. So added a resetRun() method which can be called before each run(). Also adjusted the test for this.
The isDue check on the jobs is not provided a datetime in the run() method. This means they use the creation time of the job as the 'current' time to compare against. Most likely this creation time is approx the time run() is called so normally this is no problem. But if setting up the job schedule takes more time then I would say, using the creation time as run time is unexpected. And if you run run() multiple times then it will always run the same jobs because the time never changes. So now provide an explicit run time for all jobs, which is the same for all jobs each run.
|
@merijnvdk thank you, I am happy with merging these changes, can I ask you to send this PR to the v2.x brach please? |
Remove empty line
|
I think I managed to change it to the 2.1 branch, is it correct like this? |
* Clean up * Updated phpunit * Refactoring for v2 * Refectory for v2 pt2 * Required dev php7 Phpunit v6 requires php7 to run * Fancy helpers * Prioritise jobs in background * Use temp arrays to prioritise jobs * Coveralls * Coverall config * Adjusted waiting time on test * Typo fix * Removed deprecated flag * Added Coverage badge to readme * Removed psr/log suggestion * Fixed typo in composer.json * Fixes from styleci * Downgraded phpunit Using an older version of phpunit to allow testing on php5, as phpunit v6 requires php7 * Added php 7.1 supported version * More fixes from styleci * Fixes from styleci * Reordered badges + styleci badge * Increased tests waiting time when testing file output * Typo in the documentation Ref #16 * Fix #20 Added support for SwiftMailer ^6.0 ::newInstance() method has been deprecated, along with Swift_MailTransport. The default mail transport is now sendmail when using swiftmailer https://legalhackers.com/advisories/SwiftMailer-Exploit-Remote-Code-Exec -CVE-2016-10074-Vuln.html * Implementation of #23 using `then` method Similar implementation of the PR #23 submitted by @badyto Reused the same tests on that PR There is also a possible breaking change with the output passed to the callback in the `then` method, when executing a script the output will be now an array instead of a string. * Added scheduler test This test ensures that if a job is delayed by e.g. a previous job, it will run if it was due when the scheduler ran. * Removed comment from test * Allow run() to be executed multiple times (#24) * Allow run() to be executed multiple times The current code expects the run() to be called only once. This is fine if you start the scheduler from cron each minute and re-initialize it each time. If you want to manually run the scheduler, or maybe have a lot of jobs you do not want to init each minute, it would be useful to call run() multiple times in the lifetime of the scheduler. In this case the collected data of the last run should be reset. the executedJobs, failedJobs and outputSchedule. * Allow queued jobs to be removed If the scheduler is used to do multiple runs then it would be useful to reset all queued Jobs. Currently the only way to do this is by re-creating the scheduler object. But if the object is injected in the code then this is not practical.. * Fix StyleCI analysis failure Comment format fixed. * Allow run() to be executed multiple times After discussion with @peppeocchi make the re-running manually triggered. So added a resetRun() method which can be called before each run(). Also adjusted the test for this. * Allow run() to be executed multiple times The isDue check on the jobs is not provided a datetime in the run() method. This means they use the creation time of the job as the 'current' time to compare against. Most likely this creation time is approx the time run() is called so normally this is no problem. But if setting up the job schedule takes more time then I would say, using the creation time as run time is unexpected. And if you run run() multiple times then it will always run the same jobs because the time never changes. So now provide an explicit run time for all jobs, which is the same for all jobs each run. * Fix StyleCI analysis failure Remove empty line * Allow run() to run at arbitrary time (#28) Currently when run() is called it uses the current time as the run timestamp. However it would be useful to run the scheduler at a specific time. So allow an optional param with a DateTime to run(). Reasons for running at a specific time other than now() could be: - Catching up on 'missed' runs, eg. when the system was down. - Making sure the scheduler runs at an intended timestamp eg. when cron is started at midnight it could be slow and start the php process only at 00:01 and thus missing all midnight schedules. - Improve testability of the scheduler (fake the time) * Minor change + documentation new features
The current code expects the run() to be called only once. This is
fine if you start the scheduler from cron each minute and re-initialize
it each time. If you want to manually run the scheduler, or maybe
have a lot of jobs you do not want to init each minute, it would
be useful to call run() multiple times in the lifetime of the
scheduler.
In this case the collected data of the last run should be reset.
the executedJobs, failedJobs and outputSchedule.
If the scheduler is used to do multiple runs then it would be useful
to reset all queued Jobs. Currently the only way to do this is by
re-creating the scheduler object. But if the object is injected in the
code then this is not practical.