Scheduler configs creating multiple PIDs

[AbhilashYS]

Hi All,

I have a scheduler, which scans assets and looks for expiring and send email notifications.
Here problem is instead of 1 email i am receiving 4 email for same content.

I had deployed code with with different cron expression in config file, seems all of them storing as a different PID. How do we make sure only one PID runs. here is my schedule job 

Class is made Runnable with immediate true
have OCD properties and below schedule options 

@Activate
protected void activate(Config cfg) {
    this.config = cfg;
    removeJob();
    scheduleJob(cfg);

}

@Modified
protected void modified(Config cfg) {
    removeJob();
    this.config = cfg;
    scheduleJob(cfg);
}

@Deactivate
protected void deactivate() {
    removeJob();
}

private void scheduleJob(Config cfg) {
    if (!cfg.enabled()) {
        LOG.info("AssetExpiryScheduler disabled by config.");
        return;
    }
    this.jobId = cfg.schedulerName();
    ScheduleOptions opts = scheduler.EXPR(cfg.scheduler_expression());
    opts.name(jobId);
    opts.canRunConcurrently(false);
    scheduler.schedule(this, opts);
    LOG.info("Scheduled job '{}' with expression '{}'", cfg.schedulerName(), cfg.scheduler_expression());
    this.config = cfg;

}

private void removeJob() {
    if (jobId != null) {
        scheduler.unschedule(jobId);
        jobId = null;
    }
}

[vikasbharti]

The problem is usually caused by having multiple OSGi configurations active for your scheduler, which creates several instances (PIDs) and leads to duplicate job executions and multiple email notifications.

To resolve this, consolidate your configurations so that only one configuration file for your scheduler component PID exists. You can manage OSGi configurations using the Web Console at /system/console/configMgr. If multiple configurations for the same PID are present, remove the extras and make sure only a single configuration is active.

This approach ensures that only one scheduler job runs, preventing duplicate notifications.

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/dep...

[AbhilashYS]

Thanks for the response. Yes we have made this basic check in configMgr to look for multiple PIDs. But  here we are only seeing 1 PID configuration !! Not sure why i don't see other PIDs.

For each deployment with different cron expression, I am able to see scheduler still runs even the config is changed.

I have 3 configs - config , config.dev and config.local  - This should not effect the running as only 1 will be picked at runtime based on environment.

I have service listed with 1 PID service with 1 component ID in core project bundle. and 1 config under /system/console/configMgr

Is there a way to remove existing all PID from code deployment as i am not seeing them in configMgr from developer console screen ?? 

Thanks much

[vikasbharti · Accepted solution]

Even though only one scheduler configuration appears /system/console/configMgr, old scheduler jobs can remain active in memory if they weren’t removed adequately during previous deployments or configuration changes. This can result in duplicate email notifications.

To address this, please access /system/console/slingevent The AEM Web Console displays all registered scheduled jobs. If you notice multiple jobs for your asset expiration scheduler, you can manually remove them. Additionally, ensure your code unschedules jobs whenever the configuration is modified or the bundle is deactivated. It’s also important to check that only the intended configuration file for your environment is present, as leftover or stale config files from previous deployments can cause unexpected behavior.

If multiple jobs continue to run after these checks, try restarting the relevant bundle or the entire AEM instance to clear any lingering scheduler jobs. These steps should help ensure only a single scheduler runs and prevent duplicate notifications.

[Abie]

Hi @AbhilashYS ,

It can happen on AEM cloud instance which operates in a cluster of author instances. The simple solution is to define a leader instance, please refer to the below documentation-

https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/developing/advance...

Thanks!

[AbhilashYS]

Quick update - 

What worked for us - Seems the scheduler and the service PID - both were running as class was made runnable class. 

Update - FIX Worked to remove duplicate scheduler triggers - Quick Summary 1.Removed implements Runnable - The class no longer implements Runnable. Instead, an inline Runnable was created and passed to the

scheduler.schedule() method.

2. Programmatic Scheduling -In the @activate and @MODIFIED methods, we Unschedule the existing job using scheduler.unschedule(JOB_ID).Create a new inline Runnable and schedule it with a single, stable job name (JOB_ID).

3. Leader-Only Execution -Added .onLeaderOnly(true) to the ScheduleOptions to ensure the job only runs once per cluster.

4. (Optional) Single Config File - Ensured there was only one cfg.json for the scheduler PID in the active run-mode folders