Guide · updated
Sling Jobs vs schedulers vs listeners on AEM as a Cloud Service
Background work is where many AEM 6.5 code bases quietly assume things that Cloud Service does not promise. Adobe's development guidelines are blunt: code running as a background task must assume the instance it runs on can be brought down at any time. That one sentence decides how you schedule work, react to content changes and store files.
The rules, in Adobe's words
| Topic | Adobe's guidance for Cloud Service |
|---|---|
| Scheduling | Do not use the Sling Commons Scheduler for scheduling, because execution cannot be guaranteed. |
| Long-running work | Use Sling Jobs, which have an at-least-once guarantee, and avoid restarting long jobs from scratch. |
| Event handling | Asynchronous handling of JCR events and Sling resource events cannot be guaranteed to run locally; use these mechanisms with care. |
| Local files | Do not use the instance's file system; the disk is ephemeral and disposed of when instances are recycled. |
| Outgoing HTTP | Set timeouts. Adobe suggests 1 s to connect and 5 s to read; code without timeouts gets platform limits of 10 s and 60 s. |
Replacing a scheduler with a scheduled Sling Job
- Pick a job topic, for example com/acme/jobs/sitemap.
- On component activation, register the schedule with the JobManager: createJob(topic).schedule().cron(expression).add(). Check first whether the schedule already exists so redeployments do not add duplicates.
- Move the work into a JobConsumer for that topic. Because jobs run at least once, make the consumer idempotent: running it twice must not create two copies of anything.
- Split long work into steps that record progress, so a restarted job continues instead of starting over.
Replacing JCR observation listeners
Many 6.5 projects use javax.jcr.observation.EventListener to react to content changes. On Cloud Service the usual replacement is a Sling ResourceChangeListener registered for specific paths and change types. If the reaction does work that must not be lost (sending to a search index, generating renditions, calling another system), let the listener only enqueue a Sling Job and do the work in a JobConsumer, which gives you the at-least-once guarantee the listener alone does not.
Files and temporary data
- Small temporary files inside one request are fine; nothing that must survive the request should touch disk.
- Persist results in the repository or an external store; send large artefacts to object storage you control.
How we migrate these patterns
Our scanner finds Sling Commons Scheduler use, JCR observation listeners and local file system access. Schedulers and listeners are rewritten by our AI refactoring on our own servers, checked automatically, and approved by an engineer, who also confirms the idempotency of each job consumer, because that is a design decision rather than a code change.
Questions
Can we keep using the Sling Commons Scheduler on Cloud Service?
Adobe's guidelines say not to use it for scheduling because execution cannot be guaranteed. Use scheduled Sling Jobs, which run at least once.
Are JCR observation listeners removed?
They are not on Adobe's removed-API list, but Adobe notes that asynchronous handling of JCR and Sling resource events cannot be guaranteed to run locally. For work that must happen, enqueue a Sling Job.