Introduction to delayed_job

I gave this short presentation at the November bmore-on-rails meeting last night. Flip Sasser also presented an overview of Resque, and Michael Dotterer showed us a bit about background_job.

We decided that delayed_job is an easy and solid way to get background tasks running in your Rails app, but if you are a massive site that needs a heavy-duty and configurable solution, then Resque may be what you need. Resque’s complexity makes this a non-trivial decision! Start with delayed_job since it’s so quick to implement, and you can always choose another solution later.

Want to get delayed_job running in your app in 10 minutes? Follow the steps in Delayed Gratification with Rails.

  • hoenth

    Jonathan – Great presentation last night.

    I wondered if you would know why, when using capistrano to start a delayed_job worker on passenger, it tries to start it in development mode, but the same statement run from the console starts in production.

    This is the statement I am using:
    script/delayed_job start RAILS_ENV=production

    BTW, using active_scaffold, i was able to set up a simple interface to the delayed_jobs queue, letting me see the error messages, delete items from the queue, and even edit them (set a higher priority, change the number of fails, etc.).

  • http://jonathanjulian.com jjulian

    The delayed_job capistrano recipes require that :rails_env is set. If
    not, the runner starts in development mode. In your deploy.rb, make
    sure you set :rails_env:

    set :rails_env, 'production'

    I got tripped up by this too – and I only solved it by looking at the
    source. I added a ticket over at
    http://github.com/collectiveidea/delayed_job/is