Bull Job Manager
The fastest, most reliable redis based queue for nodejs.
Carefully written for rock solid stability and atomicity.
Follow manast for news and updates regarding this library.
Are you developing bull sponsored by a company? Please, let us now!
Features:
- Minimal CPU usage by poll-free design.
- Robust design based on Redis.
- Delayed jobs.
- Retries.
- Priority.
- Concurrency.
- Pause/resume (globally or locally).
- Automatic recovery from process crashes.
UIs:
There are a few third party UIs that can be used for easier administration of the queues (not in any particular order):
We also have an official UI which is at the moment bare bones project: bull-ui
Roadmap:
- Multiple job types per queue.
- Scheduling jobs as a cron specification.
- Rate limiter for jobs.
- Parent-child jobs relationships.
Install:
npm install bull
Note that you need a redis version higher or equal than 2.8.11 for bull to work properly.
Quick Guide
var Queue = require('bull');
var videoQueue = Queue('video transcoding', 6379, '127.0.0.1');
var audioQueue = Queue('audio transcoding', 6379, '127.0.0.1');
var imageQueue = Queue('image transcoding', 6379, '127.0.0.1');
var pdfQueue = Queue('pdf transcoding', 6379, '127.0.0.1');
videoQueue.process(function(job, done){
job.progress(42);
done();
done(Error('error transcoding'));
done(null, { framerate: 29.5 });
throw (Error('some unexpected error'));
});
audioQueue.process(function(job, done){
job.progress(42);
done();
done(Error('error transcoding'));
done(null, { samplerate: 48000 });
throw (Error('some unexpected error'));
});
imageQueue.process(function(job, done){
job.progress(42);
done();
done(Error('error transcoding'));
done(null, { width: 1280, height: 720 });
throw (Error('some unexpected error'));
});
pdfQueue.process(function(job){
return pdfAsyncProcessor();
});
videoQueue.add({video: 'http://example.com/video1.mov'});
audioQueue.add({audio: 'http://example.com/audio1.mp3'});
imageQueue.add({image: 'http://example.com/image1.tiff'});
Alternatively, you can use return promises instead of using the done
callback:
videoQueue.process(function(job){
return fetchVideo(job.data.url).then(transcodeVideo);
return Promise.reject(new Error('error transcoding'));
return Promise.resolve({ framerate: 29.5 });
throw new Error('some unexpected error');
return Promise.reject(new Error('some unexpected error'));
});
A queue can be paused and resumed globally (pass true
to pause processing for
just this worker):
queue.pause().then(function(){
});
queue.resume().then(function(){
})
A queue emits also some useful events:
.on('ready', function() {
})
.on('error', function(error) {
})
.on('active', function(job, jobPromise){
})
.on('stalled', function(job){
})
.on('progress', function(job, progress){
})
.on('completed', function(job, result){
})
.on('failed', function(job, err){
})
.on('paused', function(){
})
.on('resumed', function(job){
})
.on('cleaned', function(jobs, type) {
});
Events are by default local, i.e., they only fire on the listeners that are registered on the given worker,
if you need to listen to events globally, just prefix the event with global:
:
// Local Event listener
queue.on('completed', listener):
// Global Event listener
queue.on('global:completed', listener);
Queues are cheap, so if you need many of them just create new ones with different
names:
var userJohn = Queue('john');
var userLisa = Queue('lisa');
.
.
.
Queues are robust and can be run in parallel in several threads or processes
without any risk of hazards or queue corruption. Check this simple example
using cluster to parallelize jobs across processes:
var
Queue = require('bull'),
cluster = require('cluster');
var numWorkers = 8;
var queue = Queue("test concurrent queue", 6379, '127.0.0.1');
if(cluster.isMaster){
for (var i = 0; i < numWorkers; i++) {
cluster.fork();
}
cluster.on('online', function(worker) {
for(var i=0; i<500; i++){
queue.add({foo: 'bar'});
};
});
cluster.on('exit', function(worker, code, signal) {
console.log('worker ' + worker.process.pid + ' died');
});
}else{
queue.process(function(job, jobDone){
console.log("Job done by worker", cluster.worker.id, job.jobId);
jobDone();
});
}
Important Notes
The queue aims for "at most once" working strategy. When a worker is processing a job, it will keep the job locked until the work is done. However, it is important that the worker does not lock the event loop too long, otherwise other workers could pick the job believing that the worker processing it has been stalled.
Reusing Redis connections
A standard queue requires 3 connections to a redis server. In some situations when having many queues, and using
services such as Heroku where number of connections is limited, it is desirable to reuse some connections.
This can be achieved using the "createClient" option in the queue constructor:
var client, subscriber;
client = new redis();
subscriber = new redis();
var opts = {
redis: {
opts: {
createClient: function(type){
switch(type){
case 'client':
return client;
case 'subscriber':
return subscriber;
default:
return new redis();
}
}
}
}
}
var queueFoo = new Queue('foobar', opts);
var queueQux = new Queue('quxbaz', opts);
Useful patterns
Message Queue
Bull can also be used for persistent message queues. This is a quite useful
feature in some usecases. For example, you can have two servers that need to
communicate with each other. By using a queue the servers do not need to be online
at the same time, this create a very robust communication channel. You can treat
add as send and process as receive:
Server A:
var Queue = require('bull');
var sendQueue = Queue("Server B");
var receiveQueue = Queue("Server A");
receiveQueue.process(function(job, done){
console.log("Received message", job.data.msg);
done();
});
sendQueue.add({msg:"Hello"});
Server B:
var Queue = require('bull');
var sendQueue = Queue("Server A");
var receiveQueue = Queue("Server B");
receiveQueue.process(function(job, done){
console.log("Received message", job.data.msg);
done();
});
sendQueue.add({msg:"World"});
Returning job completions
A common pattern is where you have a cluster of queue processors that just
process jobs as fast as they can, and some other services that need to take the
result of this processors and do something with it, maybe storing results in a
database.
The most robust and scalable way to accomplish this is by combining the standard
job queue with the message queue pattern: a service sends jobs to the cluster
just by opening a job queue and adding jobs to it, the cluster will start
processing as fast as it can. Everytime a job gets completed in the cluster a
message is send to a results message queue with the result data, this queue is
listened by some other service that stores the results in a database.
Documentation
Reference
Queue
Queue(queueName: string, redisPort: number, redisHost: string, redisOpts?: RedisOpts): Queue
Queue(queueName: string, redisConnectionString: string, redisOpts? RedisOpts): Queue
This is the Queue constructor. It creates a new Queue that is persisted in
Redis. Everytime the same queue is instantiated it tries to process all the
old jobs that may exist from a previous unfinished session.
Arguments
queueName {String} A unique name for this Queue.
redisPort {Number} A port where redis server is running.
redisHost {String} A host specified as IP or domain where redis is running.
redisOptions {Object} Options to pass to the redis client. https:
Alternatively, it's possible to pass a connection string to create a new queue.
Arguments
queueName {String} A unique name for this Queue.
redisConnectionString {String} A connection string containing the redis server host, port and (optional) authentication.
redisOptions {Object} Options to pass to the redis client. https:
Queue##Process
process(name?: string, concurrency?: number, processor: (job, done?) => Promise<any>)
Defines a processing function for the jobs placed into a given Queue.
The callback is called everytime a job is placed in the queue. It is passed
an instance of the job as first argument.
If the callback signature contains the second optional done
argument,
the callback will be passed a done
callback to be called after the job
has been completed. The done
callback can be called with an Error instance,
to signal that the job did not complete successfully, or with a result as
second argument as second argument (e.g.: done(null, result);
) when the
job is successful.
Errors will be passed as a second argument to the "failed" event;
results, as a second argument to the "completed" event.
If, however, the callback signature does not contain the done
argument,
a promise must be returned to signal job completion.
If the promise is rejected, the error will be passed as
a second argument to the "failed" event.
If it is resolved, its value will be the "completed" event's second argument.
A name argument can be provided so that multiple process functions can be
defined per queue. A named process will only process jobs that matches
the given name.
Note: in order to determine whether job completion is signaled by
returning a promise or calling the done
callback, Bull looks at
the length property of the callback you pass to it.
So watch out, as the following won't work:
queue.process(function(job, done) {
return Promise.resolve();
});
This, however, will:
queue.process(function(job) {
return Promise.resolve();
});
You can specify a concurrency. Bull will then call you handler in parallel respecting this max number.
Queue##add
add(name?: string, data: any, opts?: JobOpt): Promise<Job>
Creates a new job and adds it to the queue. If the queue is empty the job
will be executed directly, otherwise it will be placed in the queue and
executed as soon as possible.
An optional name can be added, so that only process functions defined
for that name will process the job.
interface JobOpts{
priority: number;
delay: number;
attempts: number;
backoff: number | BackoffOpts;
lifo: boolean;
timeout: number;
jobId: number | string;
removeOnComplete: boolean;
removeOnFail: boolean;
}
interface BackoffOpts{
type: string;
delay: number;
}
Queue##pause
pause(isLocal?: boolean): Promise
Returns a promise that resolves when the queue is paused. A paused queue will not
process new jobs until resumed, but current jobs being processed will continue until
they are finalized. The pause can be either global or local. If global, all workers
in all queue instances for a given queue will be paused. If local, just this worker will
stop processing new jobs after the current lock expires. This can be useful to stop a
worker from taking new jobs prior to shutting down.
Pausing a queue that is already paused does nothing.
Queue##resume
resume(isLocal?: boolean): Promise
Returns a promise that resolves when the queue is resumed after being paused.
The resume can be either local or global. If global, all workers in all queue
instances for a given queue will be resumed. If local, only this worker will be
resumed. Note that resuming a queue globally will not resume workers that have been
paused locally; for those, resume(true)
must be called directly on their instances.
Resuming a queue that is not paused does nothing.
Queue##count
count(): Promise<number>
Returns a promise that returns the number of jobs in the queue, waiting or
delayed. Since there may be other processes adding or processing jobs, this
value may be true only for a very small amount of time.
Queue##empty
empty(): Promise
Empties a queue deleting all the input lists and associated jobs.
Queue##close
close(): Promise
Closes the underlying redis client. Use this to perform a graceful
shutdown.
var Queue = require('bull');
var queue = Queue('example');
var after100 = _.after(100, function () {
queue.close().then(function () { console.log('done') })
});
queue.on('completed', after100);
close
can be called from anywhere, with one caveat: if called
from within a job handler the queue won't close until after
the job has been processed, so the following won't work:
queue.process(function (job, jobDone) {
handle(job);
queue.close().then(jobDone);
});
Instead, do this:
queue.process(function (job, jobDone) {
handle(job);
queue.close();
jobDone();
});
Or this:
queue.process(function (job) {
queue.close();
return handle(job).then(...);
});
Queue##getJob
getJob(jobId: string): Promise<Job>
Returns a promise that will return the job instance associated with the jobId
parameter. If the specified job cannot be located, the promise will be resolved to null
.
Queue##getJobCounts
getJobCounts() : Promise<JobCounts>
Returns a promise that will return the job counts for the given queue.
interface JobCounts {
wait: number,
active: number,
completed: number,
failed: number,
delayed: number
}
}
Queue##clean
clean(grace: number, status?: string, limit?: number): Promise<number[]>
Tells the queue remove jobs of a specific type created outside of a grace period.
Example
queue.clean(5000);
queue.clean(10000, 'failed');
queue.on('cleaned', function (job, type) {
console.log('Cleaned %s %s jobs', job.length, type);
});
Arguments
grace: number; Grace period in milliseconds.
status: string; Status of the job to clean. Values are completed, wait, active,
delayed, and failed. Defaults to completed.
limit: number; maximum amount of jobs to clean per call. If not provided will clean all matching jobs.
returns Promise; A promise that resolves with an array of removed jobs.
Events
The cleaner emits the cleaned
event anytime the queue is cleaned.
queue.on('cleaned', listener: (jobs: number[], status: string) => void);
Job
A job includes all data needed to perform its execution, as well as the progress
method needed to update its progress.
The most important property for the user is Job##data that includes the
object that was passed to Queue##add, and that is normally used to
perform the job.
Job##remove
remove(): Promise
Removes a Job from the queue from all the lists where it may be included.
Job##retry
retry(): Promise
Re-run a Job that has failed. Returns a promise that resolves when the job is scheduled for retry.
Job##discard
discard(): Promise
Ensure this job is never ran again even if attemptsMade is less than job.attempts
Job##promote
promote(): Promise
Promotes a job that is delayed to be placed on the wait state and executed as soon as
possible.
###PriorityQueue(queueName, redisPort, redisHost, [redisOpts])
DEPRECATION notice
This is the Queue constructor of priority queue. It works same a normal queue, with same function and parameters.
The only difference is that the Queue#add() allow an options opts.priority that could take
["low", "normal", "medium", "high", "critical"]. If no options provider, "normal" will be taken.
The priority queue will process more often higher priority jobs than lower.
var PriorityQueue = require("bull/lib/priority-queue");
var queue = new PriorityQueue("myPriorityQueues");
queue.add({todo: "Improve feature"}, {priority: "normal"});
queue.add({todo: "Read 9gags"}, {priority: "low"});
queue.add({todo: "Fix my test unit"}, {priority: "critical"});
queue.process(function(job, done) {
console.log("I have to: " + job.data.todo);
done();
});
Warning!!: Priority queue use 5 times more redis connections than a normal queue.
Debugging
To see debug statements set or add bull
to the NODE_DEBUG environment variable.
export NODE_DEBUG=bull
##License
(The MIT License)
Copyright (c) 2013 Manuel Astudillo manuel@optimalbits.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.