Apex Suicide Scheduler getting stuck as a queued job

Question

I have a scheduled class that I have set to run every 2 mins to check for updates from a third party system.

This had been working fine for months but lately the scheduled class is getting stuck in a status of queued.

The methods of the class are:

global void execute(SchedulableContext SC) {
    tokenCheckCrossNI();
    tokenCheckCross();

    FAChangesSchedule.start();      
    // abort me and start again
    System.abortJob( SC.getTriggerId() );
}

public static void start(){
    // start keepalive again in 2 mins
    Datetime sysTime = System.now().addSeconds(120);      
    String chronExpression = '' + sysTime.second() + ' ' + sysTime.minute() + ' ' + sysTime.hour() + ' ' + sysTime.day() + ' ' + sysTime.month() + ' ? ' + sysTime.year();
    System.schedule( 'FAChangesSchedule ' + sysTime, chronExpression, new FAChangesSchedule() );
}

I have checked the logs for this class and can't see any errors:

Could the running order of the methods within this class be causing this issue?

Is there anything I can do to get around this hanging? Or somewhere I can check why this is stuck in the queue?

Answer 1

Suicide scheduling has never been officially supported, and in fact was explicitly stated that at some point they might choose to limit it to some period of time, such as every 5 minutes minimum:

Suicidal Scheduling

While we’re on the topic of chaining, I’d like to describe another disturbing trend, one that I call “suicidal scheduling”. Suicidal scheduling is where a scheduled job enqueues another scheduled job and then aborts itself. This allows these jobs to be chained.

Try stopping this job if you want to. You can’t. It goes too quickly to be aborted. By the time you have found the job ID, the job has already run, enqueued another, and aborted itself. It’s like a virus, only you wrote it yourself, instead of unintentionally downloading it with the FREE NO ADS version of Candy Crush Saga.

We will not block this approach, since it functions today. We will, however, slow it down. Any call to System.schedule inside of a scheduled job will run no sooner than five minutes later. Ostensibly, the job is a “scheduled job”, which means it is going to repeat itself lots of times, so five minutes shouldn’t be a major issue. If it is set up simply to kill itself, throughput is going to degrade. That is good for everyone else on the pod.

(Emphasis added)

They've been threatening this for three years now. I even asked a question about this.

If you really want to improve your performance, consider scheduling 30 jobs that run hourly and are staggered every 2 minutes. Or maybe it's time to consider a new approach, like using Heroku or AWS EB, which gives you more control over the processing time in exchange for API calls.

The system has no guarantee about how long it will take asynchronous code to run at all. It could be exactly on the second, or it could be delayed by hours. The system runs jobs as fast as it can given the resources it has available. Most likely, your org has been doing too much and so the system is giving time to other orgs.

Also keep in mind that there is a 250,000/day limit on asynchronous calls, spread between batch executions, queueable, and scheduleable. If you're brushing up against that limit, that would also cause your jobs to be delayed.

Answer 2

You're trying to do something with the platform Salesforce explicitly states in the docs isn't supported. No Apex job can be scheduled to run with that kind of accuracy. 15 minutes between instances is about the best the platform tells you to expect. What you'll actually get depends on the load across the entire Pod at any given point in time.

Continuing to add jobs to the queue will only make things worse for you. See my answer to this post for more on how wait time in the queue is affected by the number jobs you've accumulated compared to other orgs on the same pod. The more you have sequenced in a row, the lower your priority will drop and the more you can expect your wait times to increase.