There is one paragraph which doesn't really make sense in that documentation:
... The Sling Event Support adds the notion of a job. A job is a special event that has to be processed exactly once. To be precise, the processing guarantee is at most once. However, the time window for a single job where exactly once is very small and only happens if the instance which processes a job crashes after the job processing is finished but before this state is persisted. Therefore a job consumer should be prepared to process a job more than once. ... I don't get that paragraph and it seems there is something missing in the sentence "However, the time window for a single job where exactly once is very small and only happens if the instance which processes a job crashes after the job processing is finished but before this state is persisted.". Even without the sentence I don't get the "at most/exactly once" guarantee, because exactly in the case where a job has been finished but its state not yet persisted would lead to execution of the job more than once. Maybe one should outline as well the case when the job is never processed at all. I assume this can only happen if there is no according JobConsumer being registered. @Carsten: Can you clarify that paragraph a bit? Thanks, Konrad > On 10 Apr 2016, at 20:55, Konrad Windszus <[email protected]> wrote: > > 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] >> <mailto:[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] >>>> <mailto:[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] <mailto:[email protected]> >>> >>> >> >> >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] <mailto:[email protected]>
