[Building Sakai] need to delay startup of quartz

[Matthew Jones]

Thanks for looking at this.

I was thinking that the *easiest* solution to this would be to just start
up the scheduler with the startDelayed(X) call rather than the .start()
call. in the ScheduleManagerImpl. [1] If we set it to be 5 minutes (or even
10 minutes) I don't think it would cause any huge issues with jobs not
running and it would be a easy few lines fix to this problem (if we wanted
to make this delay configurable). The startup time of all of our servers
never varies and always seems safe.

I think the more work solutions would be as you suggest, putting
dependencies on the jobscheduler on something else. It seems like portal is
near the end, but it's it's not always the absolute last thing. Some of the
problem we had with this was that we were scheduling a periodic restart at
exactly the same time as the autosubmit job was also scheduled to run,
which wasn't a great idea. ;)

Let me know if you want any help or anything to look at with this.

[1]
http://javadox.com/org.quartz-scheduler/quartz/1.8.6/org/quartz/core/RemotableQuartzScheduler.html#startDelayed(int)

On Tue, Jan 20, 2015 at 10:24 AM, Charles Hedrick <hedrick at rutgers.edu>
wrote:

> We need to delay the startup of quartz until the end. Either that or
> carefully audit all the jobs.
>
> We just had a system come up with Samigo non-operational.
>
> There are two static initializers calling
> IntegrationContextFactory getInstance(). In the log there’s an error from
> there, Unable to read integration context, null pointer. That implies that
> the following code failed:
>         FactoryUtil.setUseLocator(true);
>         instance = FactoryUtil.lookup();
> If you look at FactoryUtil, it ends up asking Spring for the
> bean org.sakaiproject.tool.assessment.integration.context.spring.IntegrationContext.
> But that isn’t set until the war file is deployed. But Quartz starts as
> soon as the service layer is started, before the war files have been
> deployed. So if it calls this code, the code will fail, since it depends
> upon the war file. But since it’s called from a static initializer, the
> failure is permanent.
>
> Normally it should be OK for Quartz to start when services start. Normally
> the jobs it runs are part of the service layer. This happens to be a weird
> case where the service level has a dependency upon the tool level.
>
> We can modify the Samigo job to not run unless it can get to the tool
> layer. However I think it would be better to delay the startup of Quartz
> until Sakai is fully up.
>
> My thought was to modify the init for Quartz to lazy-init, and then add an
> explicit dependency to something started very late in startup. However I
> can’t find anything appropriate. Portal seems to start last, but it doesn’t
> seem to use Spring. Can anyone think of a Spring configuration that’s done
> near the end? Another approach would be to call the init explicitly from
> the portal init code. That may be what I end up doing.
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20150120/36fb031a/attachment.html