Restarting when time changed. Several workers.

[Michael Gaganov]

Hi, John! Thanks for the rufus scheduler. 
I have a couple of questions about this gem.

In the app I have several companies. Company has setting job_run_at (hour:0-24).
So the job for each company should be run avery monday at given hour. 
It looks like:

Company.all.each do |company|

  scheduler.cron "0 #{company.job_run_at} * * 1 #{company.timezone}", :tags => 'timesheet' do

    ...

  end

end

The questions are:

1) How can I restart the current company  scheduler when job_run_at changed.
2) I use unicorn. So if I use several workers doesn't this mean that several scheduler instances will be run too at the same time?

Thank you.

Best regards, Michael.

[John Mettraux]

On Fri, Feb 08, 2013 at 02:13:18AM -0800, Michael Gaganov wrote:
>
> In the app I have several companies. Company has setting job_run_at
> (hour:0-24).
> So the job for each company should be run avery monday at given hour.
> It looks like:
>
> Company.all.each do |company|
> scheduler.cron "0 #{company.job_run_at} * * 1 #{company.timezone}", :tags
> => 'timesheet' do
> ...
> end
> end

Hello Michael,

welcome to the rufus mailing list.

Ouch, how about something like:

---8<---
scheduler.cron "0 1 * * 1", :tags => "timesheet" do
min = Time.now.min
Company.find_all(:job_run_at => min).each do
...
end
end
--->8---

So that it adapts changes to the company table...

> The questions are:
> 1) How can I restart the current company scheduler when job_run_at changed.

Well, you'd have to restart the process containing the scheduler, or simply
kill the jobs with the timesheet tag and schedule again.

I think my suggestion above would kill the need for those restarts...

> 2) I use unicorn. So if I use several workers doesn't this mean that
> several scheduler instances will be run too at the same time?

Sorry, I suggest you google for "unicorn rufus-scheduler" in this list or
globally and also read the unicorn manual. Rufus-scheduler is very dumb, it
just wants a main thread. Here on the list (and also on stack overflow iirc)
you'll find people coming up with exclusion schemes for such multiprocess
environments...


I hope it will help, best regards,

--
John Mettraux - http://lambda.io/jmettraux

[Michael Gaganov]

Thank you for the reply.

I think your suggestion is good if companies are in the same timezone.

But companies can be in different timezones.

So the task should be run every monday at given hour.

If server time is +2h then scheduler will be run not in time for company located in the timezone +4h.

Thus I need create scheduler job per each company for given timezone.

That's why I need ability to restart scheduler when company settings were changed.

So about threads again. If scheduler runs in the main thread (say  process #5), can I reach its instance from the other process to be able to restart it?

[John Mettraux]

On Fri, Feb 08, 2013 at 02:55:35AM -0800, Michael Gaganov wrote:
>
> I think your suggestion is good if companies are in the same timezone.
> But companies can be in different timezones.
> So the task should be run every monday at given hour.
> If server time is +2h then scheduler will be run not in time for company
> located in the timezone +4h.
> Thus I need create scheduler job per each company for given timezone.
> That's why I need ability to restart scheduler when company settings were
> changed.

Sorry, the code for my suggestion was simplified, it did not include the
timezone delta.

If you run every hour and include the timezone difference in the match
computation, it's sufficient.

I think that running a scheduler per company is a bad design.

> So about threads again. If scheduler runs in the main thread (say process
> #5), can I reach its instance from the other process to be able to restart
> it?

You mean "if the scheduler runs in the main process"?

Short answer: no.
Long answer: you could if you use some kind of interprocess communication
mechanism. But is it worth the cost? (See my answer above).


Best regards,

[Michael Gaganov]

Thanks for your advice. Seems you're right. I'll try.