![]() |
|
|
|
|
Issue Type:
|
![Improvement]() Improvement
|
|
Assignee:
|
Unassigned |
|
Components:
|
core |
|
Created:
|
31/Mar/14 1:53 PM
|
|
Description:
|
Currently Trigger.Cron runs every minute, checking whether any triggers are supposed to be run now. (If the task is delayed for some reason, it can check triggers in multiple waves, one per elapsed minute.) This works, but it means that if a job is not run at the expected time for some reason, the logging is nearly useless since there will be one entry per job per minute, even if jobs are set to run only at long intervals, so the log is mostly noise. Also running every minute probably wastes some CPU.
Would be better to be an AperiodicWork and calculate when it should next run, for the first job to come up. This would mean keeping a priority queue of jobs, each entry recalculated when either the trigger is run or Trigger.start is called. Such a queue would easily be dumped interactively or logged.
A complication is the anomalous behavior of SCM synchronous polling (JENKINS-806), which does not use the crontab at all and basically operates on an independent system. Probably this should just be moved into its own plugin.
|
|
Project:
|
Jenkins
|
|
Labels:
|
cron
robustness
performance
|
|
Priority:
|
![Major]() Major
|
|
Reporter:
|
Jesse Glick
|
|
|
|
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.
