search

amitree / delayed_job_recurring

Extends delayed_job to support recurring jobs
MIT License
84 stars 33 forks source link

The schedule task is idle on heroku #13

Closed bonol closed 7 years ago

bonol commented 8 years ago

I schedule my task in the initializer and deploy on heroku. It will work only when I either log into the heroku console or pay a visit on the site. For the rest of time, when the app is there without any activity, it will just turn the taks into idling mode. As I check on the log, I keep getting this(I am not sure whether it is caused by job recurring, but same action is recurring': 2016-09-21T22:40:42.281575+00:00 app[worker.1]: Delayed::Backend::ActiveRecord::Job Load (1.7ms) UPDATE "delayed_jobs" SET locked_at = '2016-09-21 22:40:42.279134', locked_by = 'host:88602f9f-7787-4e75-a6aa-d9712c27bd93 pid:3' WHERE id IN (SELECT "delayed_jobs"."id" FROM "delayed_jobs" WHERE ((run_at <= '2016-09-21 22:40:42.278448' AND (locked_at IS NULL OR locked_at < '2016-09-21 14:40:42.278498') OR locked_by = 'host:88602f9f-7787-4e75-a6aa-d9712c27bd93 pid:3') AND failed_at IS NULL) ORDER BY priority ASC, run_at ASC LIMIT 1 FOR UPDATE) RETURNING *

Also, every time when I sign into console, it will automatically remove all tasks and generate a new one, though it will generate a correct task. For example if I schedule the task to run on 11am, when I log into console at 9am the task will be removed and the same task which run_at 11am will be created.

Is there anything I can do about it to set it right? Thanks.

afn commented 7 years ago

The message you see in the log is the Delayed Job worker polling for jobs to run, which is normal.

As for the other issue, the problem stems from the fact that you're scheduling the jobs in an initializer, which gets invoked when a new Rails process starts, i.e. whenever a dyno spins up. This is going to happen each time you start a Rails console, as well as each time a web or worker dyno starts. This isn't really the right time in the app lifecycle to schedule the recurring jobs. My recommendation instead is to schedule recurring jobs whenever you deploy code. That way you don't end up rescheduling jobs unnecessarily, and you also ensure that jobs are rescheduled when they need to be (because the code has changed).