delayed_job_admin

Adding some simple admin features to delayed_job.

This project is a mountable rails engine to provide some useful admin tools to monitor your delayed jobs queue.

Getting Started

Add the gem to your Gemfile ‘gem ’delayed_job_admin’‘

Run the install ‘bundle exec rails g delayed_job_admin:install`

Run the migrations (adds a delayed_jobs_archive table) ‘bundle exec rake db:migrate`

Mount the engine in your routes.rb ‘ Rails.application.routes.draw do

...
mount DelayedJobAdmin::Engine => "/delayed_job_admin"
...

end ‘

Instead of mounting the engine you can choose to just include the controller behaviour in your own controller heirarchy. This can be done by exploiting the modules

• DelayedJobAdmin::AccessibleJobs

• DelayedJobAdmin::AccessibleArchivedJobs

‘ class Admin::DelayedJobsController < Admin::BaseController

include DelayedJobAdmin::AccessibleJobs

end ‘

You will then, obviously, need to explicitly add your controller routes to your application: ‘ resources :delayed_jobs, :only => [:index, :destroy] do

member do
  get :job_status
end

end resources :archived_delayed_jobs, :only => [:index] ‘

The install script will create three new files in your application:

• db/migrate/xxx_create_delayed_job_admin_archived_delayed_jobs.rb

• config/initializers/delayed_job_admin.rb

• config/locales/delayed_job_admin.en.yml

What do you get

1. You will have a dashboard to view your delayed_jobs. This should reside at the following URL

   <mounted_path>/jobs

2. A facility to remove jobs from the delayed_jobs table. You can write your own destroy handler and configure it in the config/initializers/delayed_job_admin.rb. The handler will be instantiated with a single parameter of the job to be ‘destroyed’ and must expose a #handle method that will be invoked on the destroy action. Multiple destroy handlers can be configured in this array and they will be run in sequence, triggered by the destroy action.

   The handling of the destroy action is configurable, however the default behaviour uses the ArchiveOnDestroyHandler. This handler will delete the job from the delayed_jobs table and store it in the archived_delayed_jobs table. This is a paranoid approach, but fits current requirements to move the job from the active queue for manual investigation later. To this end, the archived_delayed_jobs is a dead end table that will not be interacted with. Restoring or deleting jobs from this table is a manual job.

3. An API for querying the status of a job, given an ID. Paired with this is a poll_job.js utility that you can drop on any of your pages that should make it straightforward to async user-triggered tasks but still provide a synchronous-like behaviour. See spec/dummy for an example of its usage

4. Automatic alerts for your delayed job queues, with configurable alert thresholds and configurable alert handlers. There is a rake task that can be kicked off to monitor queue depth:

   >> bundle exec rake delayed_job_admin:check_queues

The idea would be that this task could be run via a cron job.

Update Notes

Version 0.0.3

The admin jobs page is too busy with a swarm of jobs that we are not very interested in (i.e. crawl jobs). These jobs are queued in batch and have the effect of transiently flooding the queue and making the admin page impossible to use.

The small change in this version allows one to specify a config setting ‘pagination_excluding_queues`. This setting takes an array of strings, representing selected queue names used in your system (defaults to empty array). This will filter out the jobs from the specified queues when populating the jobs and archived jobs index pages.

Getting started with development (i.e. running tests)

1. Clone the repo from GitHub git@github.com:ExamTime/ninja_access.git
2. cd delayed_job_admin
3. bundle install --binstubs
4. cd spec/dummy
5. bundle exec rake db:create && bundle exec rake db:migrate && bundle exec rake db:test:prepare
6. bundle exec rake