Jobs scheduled at same time exclude each other.

[thomasfedb]

If two jobs are scheduled to execute at the same time, they may be missed.

Example cronotab.rb:

Crono.perform(VeryImportantJob).every 1.day, at: {hour: 23, min: 0}
Crono.perform(OtherImportantJob).every 1.day, at: {hour: 23, min: 00}

Rather than simply taking the next job off the queue, crono should check which jobs have not been executed and which should be executed.

Psudo-code for the described logic:

init_time = Time.now

while (true)
  first = Time.now + 1.hour

  jobs.each do |job|
    next_time = job.period.occurance_since(job.last_run_time || init_time)

    if next_time.past?
      job.perform
    else
      if next_time < first
        first = next_time
      end
    end
  end

  sleep(first - Time.now)
end

[plashchynski]

Hello,

Thank you for the report, what do you think about such implementation b4ad8fb Scheduler#next_jobs simply returns all jobs scheduled at the same time.

[thomasfedb]

I still feel that you have the possibility of missing jobs while spending time spinning up threads for a batch of jobs. Have a look at the implimentation in clockwork.

[thomasfedb]

Your changes are definitely an improvement however.

[plashchynski]

The clockwork implementation is very simple and reliable. However, I would not want to do such cycle with frequent checks. It requires more CPU time, especially if there are a lot of scheduled jobs and high frequency of checks in the cycle (sleep_timeout option). I'd want the daemon to peacefully sleep until the time comes. I've improved the implementation by adding the next time cache on the job class 6d41a19 I believe it should correct such problems. if not, we will consider other variants of implementation.

[thomasfedb]

Hey. I'm away till next week and will have a look at this then.

On 13 Apr 2015, at 9:11 pm, Dzmitry Plashchynski notifications@github.com wrote:

The clockwork implementation is very simple and reliable. However, I would not want to do such cycle with frequent checks. It requires more CPU time, especially if there are a lot of scheduled jobs and high frequency of checks in the cycle (sleep_timeout option). I'd want the daemon to peacefully sleep until the time comes. I've improved the implementation by adding the next time cache on the job class 6d41a19 I believe it should correct such problems. if not, we will consider other variants of implementation.

—
Reply to this email directly or view it on GitHub.

[andre8888]

Does anyone still running into this? I have 3 jobs scheduled to run at the same time but none gets ran. I can hardly replicate this issue consistently.