Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-41389

Job Scheduler delay starting jobs during sakai startup

    XMLWordPrintable

    Details

    • 19 status:
      Resolved
    • Property addition/change required:
      Yes
    • Test Plan:
      Hide

      The job scheduler will not run scheduled jobs until after the configured (5 minutes) delay.

      Looking in the log will show what the configured value is, i.e.

      27-Feb-2019 13:47:10.766 INFO [main] org.sakaiproject.component.app.scheduler.SchedulerManagerImpl.start Scheduler will start in 5 minutes

      1) create a job and scheduled it to run every minute

      2) during Sakai startup notice the job is not run until 5 minutes after the log message from above

      [Note: Sakai trunk/master servers (MySql and Oracle) - Rebuilt daily at around 12PM and 12AM Eastern (Database cleared only at 12AM restart)]

       

      Show
      The job scheduler will not run scheduled jobs until after the configured (5 minutes) delay. Looking in the log will show what the configured value is, i.e. 27-Feb-2019 13:47:10.766 INFO [main] org.sakaiproject.component.app.scheduler.SchedulerManagerImpl.start Scheduler will start in 5 minutes 1) create a job and scheduled it to run every minute 2) during Sakai startup notice the job is not run until 5 minutes after the log message from above [Note: Sakai trunk/master servers (MySql and Oracle) - Rebuilt daily at around 12PM and 12AM Eastern (Database cleared only at 12AM restart)]  

      Description

      The Quartz Job Scheduler begins starting jobs once the Sakai Application Context has started, which is to say before Sakai has completely started (or after the ComponentManager has been refreshed but before all web applications have started.

      The proposal here is to delay the scheduler startup for minutes after the Sakai Application Context start giving Sakai a reasonable amount of time to completely start. It can be configured via:

      startSchedulerDelayMinutes@org.sakaiproject.api.app.scheduler.SchedulerManager=5

      Some of the reasoning behind this is that because the stateful jobs store a (spring bean) reference to the job itself and if the dependencies are not declared in the dependency graph some of the dependencies are not injected correctly.

      Also there is some cleanup that was performed to the SchedulerManager (aka lombokization), and the cleanup of removing the pre Quartz 2 JobType.

      Removed the use of the ComponentManager in favor of friendlier DI injection, this also fixed a bug where the SpringBeanJobWrapper was not correctly autowired.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  ern Earle R Nietzel
                  Reporter:
                  ern Earle R Nietzel
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  9 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Git Source Code