search

amitree / delayed_job_recurring

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

Delayed_job_recurring create the job multiple times. #19

Closed hugueslamy closed 7 years ago

hugueslamy commented 7 years ago

Although this is not a bug and I'll explain why in few seconds, we were having a lots of issues with recurring jobs being created and running all the times. Most of them were quick and painless, so we didn't care much about it. I just found out that we made a big mistake using delayed_job_recurring.

We derived our job class from ActiveJob::Base AND include Delayed::RecurringJob at the same time. The delayed_job_recurring documentation is correct and removing ActiveJob::Base solve the issue. This is not an obvious mistake specially if you mix recurring and non recurring jobs within your project.

My suggestion is to modify the documentation to include a small notes NOT to use ActiveJob::Base for a recurring job.

I think that it is important to leave of trace of this inattention error that could happen. You can clause this issue right away as this is only for documentation purposes.

MarkMT commented 7 years ago

I have a similar problem but apparently for a different reason. I have a recurring task scheduled from an initializer but I'm seeing duplicate DJ jobs scheduled at the same time. But unlike @hugueslamy I'm not using ActiveJob. It happens consistently on every deploy, but I can't replicate the behavior when running schedule! manually from a console.

FWIW I'm deploying to a passenger-based environment and using delayed_job 4.1.3. I don't see the same problem when restarting my thin-based development server.

Any thoughts on why this would be happening?

afn commented 7 years ago

@hugueslamy Thanks for the feedback; I'll update the documentation.

afn commented 7 years ago

@MarkMT It could be a race condition (if you're deploying several instances of the app at the same time, and you're scheduling the delayed jobs from an initializer, then all of them might be checking if the job is scheduled, finding that it's not, and scheduling an instance of it).

Rather than scheduling from an initializer, I'd recommend writing a rake task to schedule your recurring jobs and manually invoking that job on each deployment. I'll update the README accordingly.

MarkMT commented 7 years ago

Thanks.