I updated the documentation at http://sling.apache.org/documentation/bundles/apache-sling-eventing-and-job-handling.html <http://sling.apache.org/documentation/bundles/apache-sling-eventing-and-job-handling.html> in r1738459. Thanks for you input Carsten.
Konrad > On 08 Apr 2016, at 08:34, Carsten Ziegeler <[email protected]> wrote: > > 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] <mailto:[email protected]>
