Jobs scheduled at same time exclude each other. #12

New Issue

2025-12-29T00:21:11+01:00

adam commented

2025-12-29 00:21:11 +01:00

Originally created by @thomasfedb on GitHub (Apr 6, 2015).

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

Originally created by @thomasfedb on GitHub (Apr 6, 2015). If two jobs are scheduled to execute at the same time, they may be missed. Example `cronotab.rb`: ``` ruby 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: ``` ruby 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 ```

adam added the bug label 2025-12-29 00:21:11 +01:00

adam closed this issue

2025-12-29 00:21:11 +01:00

adam commented

2025-12-29 00:21:12 +01:00

@plashchynski commented on GitHub (Apr 8, 2015):

Hello,

Thank you for the report, what do you think about such implementation https://github.com/plashchynski/crono/commit/b4ad8fb953eed06914345c20021c4e06626d9727 Scheduler#next_jobs simply returns all jobs scheduled at the same time.

@plashchynski commented on GitHub (Apr 8, 2015): Hello, Thank you for the report, what do you think about such implementation https://github.com/plashchynski/crono/commit/b4ad8fb953eed06914345c20021c4e06626d9727 Scheduler#next_jobs simply returns all jobs scheduled at the same time.

adam commented

2025-12-29 00:21:12 +01:00

@thomasfedb commented on GitHub (Apr 12, 2015):

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 commented on GitHub (Apr 12, 2015): 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](https://github.com/tomykaira/clockwork).

adam commented

2025-12-29 00:21:12 +01:00

@thomasfedb commented on GitHub (Apr 12, 2015):

Your changes are definitely an improvement however.

@thomasfedb commented on GitHub (Apr 12, 2015): Your changes are definitely an improvement however.

adam commented

2025-12-29 00:21:13 +01:00

@plashchynski commented on GitHub (Apr 13, 2015):

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 https://github.com/plashchynski/crono/commit/6d41a19212888e9273530bb2aad47c5a95871ee9 I believe it should correct such problems. if not, we will consider other variants of implementation.

@plashchynski commented on GitHub (Apr 13, 2015): 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 https://github.com/plashchynski/crono/commit/6d41a19212888e9273530bb2aad47c5a95871ee9 I believe it should correct such problems. if not, we will consider other variants of implementation.

adam commented

2025-12-29 00:21:13 +01:00

@thomasfedb commented on GitHub (Apr 14, 2015):

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.

@thomasfedb commented on GitHub (Apr 14, 2015): 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.

adam commented

2025-12-29 00:21:14 +01:00

@andre8888 commented on GitHub (Aug 26, 2016):

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.

@andre8888 commented on GitHub (Aug 26, 2016): 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.

adam referenced this issue

2025-12-29 00:22:23 +01:00

[PR #12] [MERGED] Update README.md #77

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/crono#12