-1
scheduler.every '1m', :overlap => false, :mutex => "my_lock" do
   something...
end

will this scheduler's job wait for the previous run to finish or skips if it finds that previous run is still running?

1 Answers1

0

There are two cases to consider, the single process case and the multi process case.

The multi process case happens when your Rails uses a server made/tuned to use multiple Ruby processes.

By server, I mean Webrick, Unicorn, Passenger, Puma, etc...

In both cases, the overlap is considered before the mutex.

In the single process case the overlap => false will kick in first and the scheduler will skip the incoming, overlapping job. The mutex will then be considered (if the job isn't overlapping) and might make the job wait until the mutex is freed by an instance of the same job or an instance of a job pointing to that same mutex.

In the multiple process case, you might end up having a scheduler in each of your Ruby processes and overlap and mutex might appear to be not respected, while, in their local Ruby Process they are, but since you have more than one process with each a scheduler...

If you have a server giving you multiple Ruby processes and you want to have a single rufus-scheduler working on its jobs, you have to read https://github.com/jmettraux/rufus-scheduler#lockfile--mylockfiletxt and https://github.com/jmettraux/rufus-scheduler#scheduler_lock There are also multiple stackoverflow questions dedicated to this subject.

jmettraux
  • 3,511
  • 3
  • 31
  • 30