evantahler/actionHero — pull request #260 by evantahler (2013-11-23 01:33:17+00:00)
Title: Resque and v7.0.0

This Pull Request changes actionHero's backend to be compatible with Resque!
When this is merged, this will create actionHero version 7.0.0.

## Why?!

- actionHero's task system was perviously `ok`, but was custom and communicating with other systems/ecosystems was hard. Resque's ecosystem is the largest redis-based ecosystem so it was a natural fit
- it is now simple to implement priority queues for your jobs
- you can now work jobs from Rails and other projects which also share a resque-base backend (or vice-versa)
- you can now make use of great UIs, monitoring tools, etc which already exist in the resque ecosystem to manage your actionHero queues. A simple implementation of the default Resque web UI is included in this project (ruby/sinatra)

## node-resque

- [node-resque](https://github.com/taskrabbit/node-resque) was created as a stand-alone resque package to allow fo this upgrade.
- This package contains node js implementations of:
- resque
- resque scheduler
- resque-lock (plugin)
- worker-lock (plugin)

## Warnings

- NO EXISTING JOBS WILL BE COMPATIBLE FROM EARLIER ACTIONHERO VERSIONS. Your enqueued jobs will be lost

## Major Notes

- actionHero now uses resque as its task backend
- the philosophy of `any` and `all` tasks has been sacrificed in order to move to resque. All tasks are now `any` tasks, one and only one server will process that job
- recurring tasks are still allowed
- tasks now have a default queue which they will be enqueued into. You can override this at enqueue time
- tasks may now also opt into specific resque plugins (like worker-lock, which will ensure that only one instance of a job is being processed system-wide at any given time)
- workers are now defined in `config.js` by queue name(s) to allow for more detailed control. You can still run more than 1 worker per actionHero process
- If you with to use delayed or recurrent tasks, you need to run at least once instance of the `scheduler` daemon within actionHero. This can be toggled on in `config.js`. You may run more than one scheduler in your cluster .
- when actionHero is signaled to shut down, workers will be allowed to complete what they are currently working on (up to 30 seconds) before the server fully exits
- with the removal of `all` tasks, there is no longer a reason for actionHero to keep an active watch on other peers in the cluster. The `redis` initializer has been greatly simplified. There is no longer an explicit notion of `peers`, and the related methods (`api.redis.checkForDroppedPeers` and `api.redis.ping`) are removed
- a `resque` initializer has been added, and the `task` and `taskProcessor` initializers have been removed
- periodic tasks will now automatically be enqueued at boot
- `jake` helpers for tasks have been added
- jake actionHero:tasks:enqueueAllPeriodicTasks # This will enqueue all periodic tasks (could lead to duplicates)
- jake actionHero:tasks:enqueuePeriodicTask # This will enqueue a periodic task
- jake actionHero:tasks:stopPeriodicTask # This will remove an enqueued periodic task
- significant changes to `api.tasks`. The complete set of public methods is now:
- `api.tasks.enqueue(taskName, params, queue, callback)`
- `api.tasks.enqueueAt(timestamp, taskName, params, queue, callback)`
- `api.tasks.enqueueIn(time, taskName, params, queue, callback)`
- `api.tasks.del(queue, taskName, args, count, callback)`
- `api.tasks.delDelayed(queue, taskName, args, callback)`
- `api.tasks.enqueueRecurrentJob(taskName, callback)`
- `api.tasks.stopRecurrentJob(taskName, callback)`
- `api.tasks.details(callback)`

## Minor Notes

- When inspecting the status of your queue, the new method `api.tasks.details` should be used. `api.tasks.getAllTasks` and `api.tasks.getWorkerStatuses` are removed
- the task generator has been updated to reflect the above changes
- a number of `config.js` changes including
- a new `tasks` section for the resque workers
- in the redis config settings, `DB` has been renamed `database`

## Other Changes

- the validators for actions and tasks will no longer `process.exit()` when a warning is thrown (ie: a missing description). These errors will be logged and the action or task will not be loaded
- the sweeper to delete expired `api.cache` objects now will only run once a minute (previously 10 seconds)