Job Scheduler delay starting jobs during sakai startup
Description
incorporates
is related to
Activity
Austin August 27, 2019 at 7:36 PM
I opened a separate JIRA, SAK-42394, for the issue I mentioned about the NPE and autosubmit quartz job being deleted on restart with lrs.enabled=true
And the patch for that jira fixes that problem in 12.6. (However, please see my latest comment in that JIRA for details)
So I think there's nothing more needing to be done with this jira as far as 12.x (especially since Sam mentioned earlier that backporting this fix to 12.x would be difficult
Earle Nietzel August 27, 2019 at 11:20 AM
The problem I recall with this wasn't just having the scheduler start later but the use of the ComponentManager to get the spring job.
ComponentManager doesn't follow spring lifecycle so the solution here is really to stop using the ComponentManager.
Matthew Jones August 23, 2019 at 8:45 PM
Yeah, okay, might be something different. I'll look more at your email and the problem you're describing this weekend. If it only happens when LRS is enabled not as many people would be hitting it.
Austin August 23, 2019 at 8:19 PM
Hello ,
I tried applying your PR to our 12.6 instance, but unfortunately it did not fix the problem I described with the null pointer and the "Auto Submit Assessments Job" getting deleted. Perhaps what I described is a different problem. Shall I split it out into a new JIRA?
Matthew Jones August 23, 2019 at 6:49 PM
Yeah, I think we can just backport the fix specific to the issue and not all the refactoring.
It looks like the only relevant change is this line, I put a PR in for just that.
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:
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.