[Building Sakai] Why not just use quartz?

[David Horwitz]

As I understand it was done because at the time cluster support didn't
exist in Sakai ...

D



On Fri, 2013-05-17 at 10:21 +0100, Matthew Buckett wrote:
> On the CLE team call yesterday this ticket came up:
>
>
> https://jira.sakaiproject.org/browse/SAK-23130
>
>
> An when looking at this I wondered why Sakai seems to have it's own
> scheduled invokation manager which stores in a table a list of jobs to
> be run at some point in the future and every x seconds a quartz jobs
> fires which runs any jobs that need to be run and then removes them
> from the table.
>
>
> Does anyone know why we didn't just use quartz as wouldn't it be
> easier to just create the jobs in quartz with simple triggers as that
> what it's designed for.
>
>
> I've had a quick look in jira/svn but can't find anything about why
> this implementation was taken.
>
>
> Having the API seems sensible so that callers don't bind directly
> against quartz, but it would seem sensible to have the implementation
> just proxy requests directly through to quartz.
>
>
> --
>   Matthew Buckett, VLE Developer, IT Services, University of Oxford
> _______________________________________________
> 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"

________________________________
 UNIVERSITY OF CAPE TOWN

This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.