Agenda
Agenda is a light-weight job scheduling library for Node.js.
It offers:
- Minimal overhead. Agenda aims to keep its code base small.
- Mongo backed persistance layer.
- Scheduling with configurable priority, concurrency, and repeating
- Scheduling via cron or human readable syntax.
- Event backed job queue that you can hook into.
- Optional standalone web-interfaces (see agendash and agenda-ui)
Installation
Install via NPM
npm install agenda
You will also need a working mongo database (2.6+) to point it to.
Example Usage
var mongoConnectionString = "mongodb://127.0.0.1/agenda"; var agenda = db: address: mongoConnectionString; // or override the default collection name:// var agenda = new Agenda({db: {address: mongoConnectionString, collection: "jobCollectionName"}}); // or pass additional connection options:// var agenda = new Agenda({db: {address: mongoConnectionString, collection: "jobCollectionName", options: {server:{auto_reconnect:true}}}); // or pass in an existing mongodb-native MongoClient instance// var agenda = new Agenda({mongo: myMongoClient}); agenda; agenda;
agenda; agenda;
agenda;
Full documentation
Agenda's basic control structure is an instance of an agenda. Agenda's are mapped to a database collection and load the jobs from within.
Table of Contents
- Configuring an agenda
- Agenda Events
- Defining job processors
- Creating jobs
- Managing jobs
- Starting the job processor
- Multiple job processors
- Manually working with jobs
- Job Queue Events
- Frequently asked questions
- Example Project structure
- Acknowledgements
Configuring an agenda
All configuration methods are chainable, meaning you can do something like:
var agenda = ;agenda ...;
Agenda uses Human Interval for specifying the intervals. It supports the following units:
seconds
, minutes
, hours
, days
,weeks
, months
-- assumes 30 days, years
-- assumes 365 days
More sophisticated examples
agenda;agenda;agenda;agenda;
database(url, [collectionName])
Specifies the database at the url
specified. If no collection name is given,
agendaJobs
is used.
agenda;
You can also specify it during instantiation.
var agenda = db: address: 'localhost:27017/agenda-test' collection: 'agendaJobs' ;
Agenda will emit a ready
event (see Agenda Events) when properly connected to the database and it is safe to start using Agenda.
mongo(mongoClientInstance)
Use an existing mongodb-native MongoClient instance. This can help consolidate connections to a
database. You can instead use .database
to have agenda handle connecting for
you.
Please note that this must be a collection. Also, you will want to run the following afterwards to ensure the database has the proper indexes:
{} agenda_db;
You can also specify it during instantiation.
var agenda = mongo: mongoClientInstance;
name(name)
Takes a string name
and sets lastModifiedBy
to it in the job database.
Useful for if you have multiple job processors (agendas) and want to see which
job queue last ran the job.
agendanameoshostname + '-' + processpid;
You can also specify it during instantiation
var agenda = name: 'test queue';
processEvery(interval)
Takes a string interval
which can be either a traditional javascript number,
or a string such as 3 minutes
Specifies the frequency at which agenda will query the database looking for jobs
that need to be processed. Agenda internally uses setTimeout
to guarantee that
jobs run at (close to ~3ms) the right time.
Decreasing the frequency will result in fewer database queries, but more jobs being stored in memory.
Also worth noting is that if the job is queue is shutdown, any jobs stored in memory that haven't run will still be locked, meaning that you may have to wait for the lock to expire.
agenda;
You can also specify it during instantiation
var agenda = processEvery: '30 seconds';
maxConcurrency(number)
Takes a number
which specifies the max number of jobs that can be running at
any given moment. By default it is 20
.
agenda;
You can also specify it during instantiation
var agenda = maxConcurrency: 20;
defaultConcurrency(number)
Takes a number
which specifies the default number of a specific job that can be running at
any given moment. By default it is 5
.
agenda;
You can also specify it during instantiation
var agenda = defaultConcurrency: 5;
lockLimit(number)
Takes a number
which specifies the max number jobs that can be locked at any given moment. By default it is 0
for no max.
agenda;
You can also specify it during instantiation
var agenda = lockLimit: 0;
defaultLockLimit(number)
Takes a number
which specifies the default number of a specific job that can be locked at any given moment. By default it is 0
for no max.
agenda;
You can also specify it during instantiation
var agenda = defaultLockLimit: 0;
defaultLockLifetime(number)
Takes a number
which specifies the default lock lifetime in milliseconds. By
default it is 10 minutes. This can be overridden by specifying the
lockLifetime
option to a defined job.
A job will unlock if it is finished (ie. done
is called) before the lockLifetime
.
The lock is useful if the job crashes or times out.
agenda;
You can also specify it during instantiation
var agenda = defaultLockLifetime: 10000;
Agenda Events
An instance of an agenda will emit the following events:
ready
- called when Agenda mongo connection is successfully openederror
- called when Agenda mongo connection process has thrown an error
agenda;
Defining Job Processors
Before you can use a job, you must define its processing behavior.
define(jobName, [options], fn)
Defines a job with the name of jobName
. When a job of jobName
gets run, it
will be passed to fn(job, done)
. To maintain asynchronous behavior, you must
call done()
when you are processing the job. If your function is synchronous,
you may omit done
from the signature.
options
is an optional argument which can overwrite the defaults. It can take
the following:
concurrency
:number
maximum number of that job that can be running at once (per instance of agenda)lockLimit
:number
maximum number of that job that can be locked at once (per instance of agenda)lockLifetime
:number
interval in ms of how long the job stays locked for (see multiple job processors for more info). A job will automatically unlock ifdone()
is called.priority
:(lowest|low|normal|high|highest|number)
specifies the priority of the job. Higher priority jobs will run first. See the priority mapping below
Priority mapping:
{
highest: 20,
high: 10,
default: 0,
low: -10,
lowest: -20
}
Async Job:
agenda;
Sync Job:
agenda;
Creating Jobs
every(interval, name, [data], [options], [cb])
Runs job name
at the given interval
. Optionally, data and options can be passed in.
Every creates a job of type single
, which means that it will only create one
job in the database, even if that line is run multiple times. This lets you put
it in a file that may get run multiple times, such as webserver.js
which may
reboot from time to time.
interval
can be a human-readable format String
, a cron format String
, or a Number
.
data
is an optional argument that will be passed to the processing function
under job.attrs.data
.
options
is an optional argument that will be passed to job.repeatEvery
. In order to use
this argument, data
must also be specified.
cb
is an optional callback function which will be called when the job has been
persisted in the database.
Returns the job
.
agenda; agenda;
Optionally, name
could be array of job names, which is convenient for scheduling
different jobs for same interval
.
agenda;
In this case, every
returns array of jobs
.
schedule(when, name, [data], [cb])
Schedules a job to run name
once at a given time. when
can be a Date
or a
String
such as tomorrow at 5pm
.
data
is an optional argument that will be passed to the processing function
under job.attrs.data
.
cb
is an optional callback function which will be called when the job has been
persisted in the database.
Returns the job
.
agenda;
Optionally, name
could be array of job names, similar to every
method.
agenda;
In this case, schedule
returns array of jobs
.
now(name, [data], [cb])
Schedules a job to run name
once immediately.
data
is an optional argument that will be passed to the processing function
under job.attrs.data
.
cb
is an optional callback function which will be called when the job has been
persisted in the database.
Returns the job
.
agenda;
create(jobName, data)
Returns an instance of a jobName
with data
. This does NOT save the job in
the database. See below to learn how to manually work with jobs.
var job = agenda;job;
Managing Jobs
jobs(mongodb-native query)
Lets you query all of the jobs in the agenda job's database. This is a full mongodb-native
find
query. See mongodb-native's documentation for details.
agenda;
cancel(mongodb-native query, cb)
Cancels any jobs matching the passed mongodb-native query, and removes them from the database.
agenda;
This functionality can also be achieved by first retrieving all the jobs from the database using agenda.jobs()
, looping through the resulting array and calling job.remove()
on each. It is however preferable to use agenda.cancel()
for this use case, as this ensures the operation is atomic.
purge(cb)
Removes all jobs in the database without defined behaviors. Useful if you change a definition name and want to remove old jobs.
IMPORTANT: Do not run this before you finish defining all of your jobs. If you do, you will nuke your database of jobs.
agenda;
Starting the job processor
To get agenda to start processing jobs from the database you must start it. This
will schedule an interval (based on processEvery
) to check for new jobs and
run them. You can also stop the queue.
start
Starts the job queue processing, checking processEvery
time to see if there
are new jobs.
stop
Stops the job queue processing. Unlocks currently running jobs.
This can be very useful for graceful shutdowns so that currently running/grabbed jobs are abandoned so that other job queues can grab them / they are unlocked should the job queue start again. Here is an example of how to do a graceful shutdown.
{ agenda;} process;process;
Multiple job processors
Sometimes you may want to have multiple node instances / machines process from the same queue. Agenda supports a locking mechanism to ensure that multiple queues don't process the same job.
You can configure the locking mechanism by specifying lockLifetime
as an
interval when defining the job.
agenda;
This will ensure that no other job processor (this one included) attempts to run the job again for the next 10 seconds. If you have a particularly long running job, you will want to specify a longer lockLifetime.
By default it is 10 minutes. Typically you shouldn't have a job that runs for 10 minutes, so this is really insurance should the job queue crash before the job is unlocked.
When a job is finished (ie. done
is called), it will automatically unlock.
Manually working with a job
A job instance has many instance methods. All mutating methods must be followed
with a call to job.save()
in order to persist the changes to the database.
repeatEvery(interval, [options])
Specifies an interval
on which the job should repeat.
interval
can be a human-readable format String
, a cron format String
, or a Number
.
options
is an optional argument that can include a timezone
field. The timezone should
be a string as accepted by moment-timezone and is considered
when using an interval in the cron string format.
options
also can optionally contain startDate
and endDate
which takes a dates in "YYYY-MM-DD" format. This is to be considered when using interval in the cron string format. If startDate
and endDate
are present, the job only runs between the start date and end date. If the endDate
is not present, then the job only runs after the start date and can continue to run as per schedule endlessly.
options
also can optionally contain skipDays
which takes days in number / string format. This is used to skip the next run time of the job by x days, where x is the skipDays. This is to be used to handle use cases like "run every x days". This is to be used with an interval in cron string format.
job;job;
job;job;
job;job;
repeatAt(time)
Specifies a time
when the job should repeat. Possible values
job;job;
schedule(time)
Specifies the next time
at which the job should run.
job;job;
priority(priority)
Specifies the priority
weighting of the job. Can be a number or a string from
the above priority table.
job;job;
unique(properties, [options])
Ensure that only one instance of this job exists with the specified properties
options
is an optional argument which can overwrite the defaults. It can take
the following:
insertOnly
:boolean
will prevent any properties from persisting if job already exists. Defaults to false.
job;job;
fail(reason)
Sets job.attrs.failedAt
to now
, and sets job.attrs.failReason
to reason
.
Optionally, reason
can be an error, in which case job.attrs.failReason
will
be set to error.message
job;// orjob;job;
run(callback)
Runs the given job
and calls callback(err, job)
upon completion. Normally
you never need to call this manually.
job;
save(callback)
Saves the job.attrs
into the database.
job
remove(callback)
Removes the job
from the database.
job
touch(callback)
Resets the lock on the job. Useful to indicate that the job hasn't timed out when you have very long running jobs.
agenda;
Job Queue Events
An instance of an agenda will emit the following events:
start
- called just before a job startsstart:job name
- called just before the specified job starts
agenda;
complete
- called when a job finishes, regardless of if it succeeds or failscomplete:job name
- called when a job finishes, regardless of if it succeeds or fails
agenda;
success
- called when a job finishes successfullysuccess:job name
- called when a job finishes successfully
agenda;
fail
- called when a job throws an errorfail:job name
- called when a job throws an error
agenda;
Frequently Asked Questions
Sample Project Structure?
Agenda doesn't have a preferred project structure and leaves it to the user to choose how they would like to use it. That being said, you can check out the example project structure below.
Can I Donate?
Thanks! I'm flattered, but it's really not necessary. If you really want to, you can find my gittip here.
Web Interface?
Agenda itself does not have a web interface built in. That being said, there are two stand-alone web interfaces:
Mongo vs Redis
The decision to use Mongo instead of Redis is intentional. Redis is often used for non-essential data (such as sessions) and without configuration doesn't guarantee the same level of persistence as Mongo (should the server need to be restarted/crash).
Agenda decides to focus on persistence without requiring special configuration of Redis (thereby degrading the performance of the Redis server on non-critical data, such as sessions).
Ultimately if enough people want a Redis driver instead of Mongo, I will write one. (Please open an issue requesting it). For now, Agenda decided to focus on guaranteed persistence.
Spawning / forking processes.
Ultimately Agenda can work from a single job queue across multiple machines, node processes, or forks. If you are interested in having more than one worker, Bars3s has written up a fantastic example of how one might do it:
var cluster = cpuCount = length jobWorkers = webWorkers = ; if clusterisMaster // Create a worker for each CPU for var i = 0; i < cpuCount; i += 1 ; ; cluster; else if processenvweb console; ;//initialize the http server here if processenvjob console; ;//initialize the agenda here { webWorkers;} { jobWorkers;} { webWorkers;} { jobWorkers;}
Example Project Structure
Agenda will only process jobs that it has definitions for. This allows you to selectively choose which jobs a given agenda will process.
Consider the following project structure, which allows us to share models with the rest of our code base, and specify which jobs a worker processes, if any at all.
- server.js
- worker.js
lib/
- agenda.js
controllers/
- user-controller.js
jobs/
- email.js
- video-processing.js
- image-processing.js
models/
- user-model.js
- blog-post.model.js
Sample job processor (eg. jobs/email.js
)
var email = User = ; module { agenda; agenda // More email related jobs}
lib/agenda.js
var Agenda = ; var agenda = connectionOpts; var jobTypes = processenvJOB_TYPES ? processenvJOB_TYPES : ; jobTypes ifjobTypeslength agendastart; moduleexports = agenda;
lib/controllers/user-controller.js
var app = User = agenda = ; app;
worker.js
;
Now you can do the following in your project:
node server.js
Fire up an instance with no JOB_TYPES
, giving you the ability to process jobs,
but not wasting resources processing jobs.
JOB_TYPES=email node server.js
Allow your http server to process email jobs.
JOB_TYPES=email node worker.js
Fire up an instance that processes email jobs.
JOB_TYPES=video-processing,image-processing node worker.js
Fire up an instance that processes video-processing/image-processing jobs. Good for a heavy hitting server.
Acknowledgements
Agenda has some great community members that help a great deal.
License
(The MIT License)
Copyright (c) 2013 Ryan Schmukler ryan@slingingcode.com
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.