User tests: Successful: Unsuccessful:
porting of joomla-projects/privacy-framework#133
Pull Request for Issue #20839
a basic job scheduler system to be able to schedule and execute tasks that could be run as:
onAfterRespond
eventplugins.
scheduler
it runs at scheduled time
it trigger the onExecuteScheduledTask
event from the new job plugin group
can be triggered from a webcron service
logrotation
when triggered (even from cli/cron) it runs at scheduled time
the CLI script
scheduler
scriptit trigger the onExecuteScheduledTask
event from the new job plugin group
apply PR and discover
install the system scheduler plugin
install the job logrotation plugin
disable the system log rotation plugin
enable the debug
additionally you can install these 2 sample job plugin
plg_jobone.zip
plg_jobtwo.zip
wich do quite nothing, just sleep for some seconds, useful to help testing concurrency
the scheduler system plugin
the job plugin
i can suggest to test with the ApacheBench tool
if you want to test the webcron way
ab -n 1000 -c 50 http://yoursite/?webcronkey=mysecretkey
or without a webcron
ab -n 1000 -c 50 http://yoursite/
for those lucky enough to use a cron job simply schedule/run from CLI
php cli/scheduler.php
the execution can be checked in the log path
and should look like something like this , depending on your plugin settings
even without a cron facilities you are able to schedule job's
n.a
it can be easly used for tasks like:
etc...
if approved
convert the old plugins that use directly onAfterRespond
event
the sql install/update script
Status | New | ⇒ | Pending |
Category | ⇒ | CLI Front End Plugins |
@alikon Personally I am not so in favor for the poor man's cron but I am not against it though. Let me explain. First of all, if a host doesn't offer cron job facilities, it's time to look for another host. Second, it doesn't offer the same options as a real cron job. You cannot run the Joomla CLI files as we check if you are on the CLI. You cannot be sure the job is executed at the set time, you are depending on the visitor. Third, the user who happens to visit the site and trigger the job has to wait until the job is finished. Fourth, you are limited to the max_execution_time of your host. If your host doesn't offer real cron jobs, this is most likely not exceeding the 30 second mark.
There is also a service for this like https://www.easycron.com/ which can trigger cronjobs if your host doesn't support it.
Users usually don't understand these limitations and if this goes in we should be very clear about this. As an extension developer that relies a lot on cronjobs I have seen the problems that these poor man crons give. In my case it is users importing huge amounts of data and wondering why it crashes or takes so long. I can see the questions coming that the cron doesn't work.
Just my 3 cents :)
@roland-d I agree with all your points. No question about it - a real cron will always be better. However this is much more beginner friendly and for those people who regularly move hosts it has the advantage of being portable. As long as there is a notice pointing out that a real cron is better etc then I don't see an issue with this.
@roland-d should be noticed that drupal has a "poor mans cron" see https://www.drupal.org/docs/8/cron-automated-tasks/cron-automated-tasks-overview
There is also a similar capability in WordPress - https://developer.wordpress.org/plugins/cron/
As an extension developer that relies a lot on cronjobs I have seen the problems that these poor man crons give.
Similar to the session GC capabilities added in 3.8, when complete this should be able to run in a way where the actual task runners can execute in either a web context or through a CLI script (then someone who can and does set up a proper cron at the server level can turn off the web based executor, probably a plugin, and rely on the server's cron to run things).
sorry folks for my late reply.... even if i'm lazy.... i'm still working on this task (with my times, sorry ) ... for me this it is a very important task
@roland-d all your concerns are mine's too... and the same i think for the other's who cares about this matter
for sure we cannot equiparate a cron with a web-cron we all agree on this...
and this must be crystal clear when and if this [wip] pr will go in to the core
...my simulations with tools like ApacheBench are smoothly going quite well, my first goal is to manage concurrency for the web side... for the cron side if we a have a normal sysadmin ... maybe we should'nt need to manage that issue....
i'll come back with some still "new and dirty code" quite soon...
Labels |
Added:
?
|
Category | CLI Front End Plugins | ⇒ | Administration Language & Strings CLI Front End Plugins |
Labels |
Added:
?
|
Category | CLI Front End Plugins Administration Language & Strings | ⇒ | Administration Language & Strings CLI Libraries Front End Plugins |
Category | CLI Front End Plugins Administration Language & Strings Libraries | ⇒ | Administration Language & Strings CLI SQL Installation Libraries Front End Plugins |
Title |
|
updated the pr description&test info accordingly to the latest changes
@roland-d should be noticed that drupal has a "poor mans cron" see https://www.drupal.org/docs/8/cron-automated-tasks/cron-automated-tasks-overview
Shopware has one, TYPO3 of course.
In both examples, it is more about setting up the cronjobs, ie the tasks and how often they should run.
It must then continue to run a real cron job on the host, which calls the scheduler. For example. every 5 minutes, the scheduler is called up and then looks if one of the jobs has to be processed and leaves it running. In Shopware, the answer will be displayed partly in the settings of the respective task with values, or a true false. It can even be set to be notified by false via email or even the task is set to inactive.
Category | CLI Front End Plugins Administration Language & Strings Libraries SQL Installation | ⇒ | Administration CLI Front End Installation Libraries Plugins SQL |
Title |
|
Category | CLI Front End Plugins Administration Libraries SQL Installation | ⇒ | Administration Language & Strings CLI SQL Installation Libraries Front End Plugins |
As new Feature this should be rebased on J4.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-04-26 12:50:51 |
Closed_By | ⇒ | HLeithner | |
Labels |
Added:
?
Removed: J3 Issue ? |
@Quy i will be happy to fix all CS related issues,?
just need some kind of green light before