Hi Carsten, thanks a lot for that information. I try to update the documentation around scheduling soon. Could you please confirm that I got the f flow for scheduling correct from the code: Once you schedule a Sling Scheduled Job, it will be persisted in the JCR (so in case of a Sling server crashing, that information won't be lost). After it has been scheduled the commons scheduler service takes care of putting the real Sling Job at the appropriate time into the queue (i.e. will just add it as regular Sling Job). From there on everything works like a regular Sling Job.
Is this correct? If it is like that I would rather recommend to use Sling Scheduled Jobs for most of the cases, because it provides the following advantages over just using Commons Scheduler - Job Execution may take place on another instance - Scheduled jobs don't get lost during a restart Thanks, Konrad > On 07 Apr 2016, at 06:43, Carsten Ziegeler <[email protected]> wrote: > > Carsten Ziegeler wrote >> Hi, >> >> first of all we have a terminology problem: the term job is overloaded. >> While both modules talk about jobs they mean different things. >> >> The commons scheduler is a general purpose scheduler (based on Quartz). >> It allows to schedule "things" (quartz calls them jobs), basically a >> runnable which gets executed on the instance where it is scheduled based >> on the schedule. As you pass java objects (runnables or equivalent) to >> the scheduler, and these objects might reference other things like OSGi >> services etc. these can't be persisted in a general version. Therefore >> it is up to the caller to make sure that the right action is performed >> if the server restarts. >> Typical use cases include periodically pinging remote servers to check >> if they are still there etc. >> >> The scheduled jobs as part of the Sling Event module have been added a >> long time back and where in the initial code base (long before >> SLING-3028). A Sling job is a task that is executed exactly once >> somewhere in a clustered installation. (Of course single server works as >> well, and exactly once is only achieved under specific circumstances). >> Usually such a job is generated ad hoc, like "process this workflow", >> "encode this video" etc. > > So this is a queue based publish-subscribe mechanism. With commons > scheduler you schedule the task that executes, with Sling jobs you put a > job description in a queue, and someone is processing it. > >> However there are some uses cases where you want to make sure that a job >> is periodically performed. In this case, the job scheduler gets a >> template for a job and fires it periodically. And the executer makes >> sure that this job is executed once, somewhere based on the configuration. >> >> Now, we could get rid of these scheduled jobs as you can also use the >> commons scheduler for this. But I'm not sure if it is worth the effort. >> > > Carsten > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
