Konrad Windszus wrote > Hi Carsten, thanks a lot for that information. I try to update the > documentation around scheduling soon.
Great thanks > 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? Yes :) > > 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 It depends on the use case, e.g. if you want to refresh every 3 minutes a cache the commons scheduler works perfectly and has close to zero overhead. The Sling jobs are really heavy weight but provide other characteristics. Carsten > > 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] > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
