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]
