How to Update or Delete Scheduled Jobs Under /var/eventing/scheduled-jobs When Cron Expression Changes

[KeerthanaS]

Hi Team

I am working with scheduled jobs in AEM and have encountered a scenario where a job is initially configured with a 10-minute cron expression. Later, the requirement changes, and the cron expression needs to be updated to trigger the job every hour. The cron expression is sourced from the OSGi configuration.

However, when the cron expression is updated, the existing job under /var/eventing/scheduled-jobs is not modified. Instead, a new job node is created with the updated cron expression, resulting in both the old (10-minute) and new (1-hour) jobs running simultaneously. This is not the intended behavior.

I attempted to delete the old job programmatically, but it appears that the APIs do not provide a straightforward way to remove or update these job nodes directly.

Although it is possible to manually delete the old job or modify the job directly in CRXDE, this approach is not a sustainable solution and is not considered a best practice.

I would appreciate guidance on how to automate the process of updating an existing scheduled job's cron expression or how to properly remove the old job node from /var/eventing/scheduled-jobs when the cron expression changes.

Thank you for your assistance!

Regards
Keerthana S

[arunpatidar]

HI @KeerthanaS 

Scripting can help to get jobs with specific topics and remove those. You can run that script after the deployment. It could be a groovy script.

https://techrevel.blog/2023/11/06/enhancing-efficiency-and-reliability-by-sling-jobs/ 

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/aem-6-1-sling-jobs-unsched... 

[KeerthanaS]

Hi @arun 

Thank you for your response.

I am currently deleting the scheduled jobs by retrieving the associated resource, accessing the underlying node, and removing it. If the cron expression is updated, I delete the existing job and create a new one. This approach is working as expected on the author instance. However, I have noticed that the scheduled jobs still persist on the publish instance.

Is there a recommended way to remove these jobs from the publish environment as well?

Regards
Keerthana S

[KeerthanaS]

My apologies, @arunpatidar  — I overlooked this point.
I must ensure that any previously scheduled jobs are properly deleted for the publish instance. 
An early response would be greatly appreciated.

Thank you.

Regards,
Keerthana S

[SantoshSai]

Hi @KeerthanaS,

Agree with @arunpatidar!

Updating a cron expression via OSGi for a scheduled job in AEM does not automatically clean up the old job node under /var/eventing/scheduled-jobs. This leads to multiple scheduled jobs running concurrently, which is clearly not the intended behavior.

When a job is registered with a new cron expression, AEM sees it as a new job instance (even if it's from the same scheduler class), because it uses a different internal job ID (usually based on cron + topic + component details). The old job is not removed automatically.

Option 1: Groovy script to clean up old jobs

You can use a post-deployment Groovy script (via ACS Commons) to programmatically find and delete job nodes based on their topic, name, or even the old cron expression pattern.

Here's an example snippet:

def session = resourceResolver.adaptTo(javax.jcr.Session)
def path = "/var/eventing/scheduled-jobs"

def node = session.getNode(path)
node.nodes.each {
    if (it.name.contains("your-scheduler-topic-or-job-name")) {
        it.remove()
        println "Removed job node: ${it.path}"
    }
}
session.save()

You can schedule this script to run post-deploy, or even bind it to an OSGi lifecycle listener if needed.

Option 2: Lifecycle Hook / OSGi Activator Logic

Implement logic in your scheduler’s @Activate method to:

• Check for existing scheduled jobs (via the JobManager or directly inspecting /var/eventing/scheduled-jobs)

• Compare cron expressions

• Remove or deactivate obsolete entries

However, be cautious — Sling APIs don't expose deletion methods for scheduled jobs, so you’d fall back to JCR node manipulation like in the Groovy script above.

Hope that helps!

Regards,
Santosh

[KeerthanaS]

Hi @SantoshSai 

I followed your second option, and it worked as expected on the author instance. However, I do not want the job to run on the publish instance. I have already made the necessary code changes to ensure it only runs on author, but the previously existing jobs are still present on the publish environment.

Is there a recommended approach to remove these existing jobs from publish?

Regards
Keerthana S

[kautuk_sahni]

@KeerthanaS Did you find the suggestions helpful? If you need more information, please let us know. If a response resolved your issue, kindly mark it as correct to help others in the future. Alternatively, if you discovered a solution on your own, we'd appreciate it if you could share it with the community. Thank you.