Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More →
bee-queue - npm Package Compare versions
Comparing version 1.1.0 to 1.2.0
| { | ||
| "name": "bee-queue", | ||
| "version": "1.1.0", | ||
| "version": "1.2.0", | ||
| "description": "A simple, fast, robust job/task queue, backed by Redis.", | ||
@@ -26,2 +26,3 @@ "main": "index.js", | ||
| "index.js", | ||
| "index.d.ts", | ||
| "lib" | ||
@@ -28,0 +29,0 @@ ], |
@@ -31,3 +31,3 @@ <a name="top"></a> | ||
| Thanks to the folks at [Mixmax](https://mixmax.com), Bee-Queue is once again being regularly maintained! | ||
| Thanks to the folks at [Mixmax](https://mixmax.com), Bee-Queue is once again being regularly [maintained](https://mixmax.com/blog/bee-queue-v1-node-redis-queue)! | ||
@@ -100,18 +100,6 @@ [Celery](http://www.celeryproject.org/), [Resque](https://github.com/resque/resque), [Kue](https://github.com/Automattic/kue), and [Bull](https://github.com/OptimalBits/bull) operate similarly, but are generally designed for longer background jobs, supporting things like job prioritization and repeatable jobs, which Bee-Queue [currently does not](#contributing). Bee-Queue can handle longer background jobs just fine, but they aren't [the primary focus](#motivation). | ||
|  | ||
|  | ||
| See the raw data [here](https://raw.githubusercontent.com/bee-queue/bee-queue/master/summary-2017-07-20.txt). | ||
| These basic benchmarks ran 10,000 jobs through each library, at varying levels of concurrency, with Node.js (v6.9.1, v6.11.2, v7.6.0, v7.10.1, v8.2.1, v8.3.0) and Redis (v3.2.10, v4.0.1) running directly on an Amazon AWS EC2 m4.large. The numbers shown are averages of 36 runs, 3 for each combination of the aforementioned Redis and Node versions. The raw data collected and code used are available in the [benchmark folder](https://github.com/bee-queue/bee-queue/tree/master/benchmark/results-2017-08-12). | ||
| These basic benchmarks ran 10,000 jobs through each library, at varying levels of concurrency, with Node.js (v6.9.1, v7.6.0, and v8.2.0) and Redis 3.2.9 running directly on an AWS m4.xlarge. The numbers shown are averages of 3 runs; the raw data collected and code used are available in the benchmark folder. | ||
| For a rough idea of space efficiency, the following table contains Redis memory usage as reported by [INFO](http://redis.io/commands/INFO) after doing a [FLUSHALL](http://redis.io/commands/FLUSHALL), restarting Redis, and running a single basic 10k job benchmark: | ||
| | Library | Memory After | Memory Peak | Memory After Δ | Memory Peak Δ | | ||
| | --------- | ------------- | ----------- | -------------- | ------------- | | ||
| | Bee-Queue | 2.65MB | 2.73MB | 1.67MB | 1.75MB | | ||
| | Bull | 3.93MB | 5.09MB | 2.95MB | 4.11MB | | ||
| | Kue | 7.53MB | 7.86MB | 6.55MB | 6.88MB | | ||
| The Δ columns factor out the ~986KB of memory usage reported by Redis on a fresh startup. Note that this data was collected in 2015, but should still accurately reflect the memory usage of Bee-Queue. | ||
| # Web Interface | ||
@@ -241,3 +229,3 @@ | ||
| To make this happen, workers periodically phone home to Redis about each job they're working on, just to say "I'm still working on this and I haven't stalled, so you don't need to retry it." The [`checkStalledJobs`](#queuecheckstalledjobsinterval-cb) method finds any active jobs whose workers have gone silent (not phoned home for at least [`stallInterval`](#settings) ms), assumes they have stalled, and re-enqueues them. | ||
| To make this happen, workers periodically phone home to Redis about each job they're working on, just to say "I'm still working on this and I haven't stalled, so you don't need to retry it." The [`checkStalledJobs`](#queuecheckstalledjobsinterval-cb) method finds any active jobs whose workers have gone silent (not phoned home for at least [`stallInterval`](#settings) ms), assumes they have stalled, emits a `stalled` event with the job id, and re-enqueues them to be picked up by another worker. | ||
@@ -361,2 +349,12 @@ # API Reference | ||
| #### stalled | ||
| ```js | ||
| queue.on('stalled', (jobId) => { | ||
| console.log(`Job ${jobId} stalled and will be reprocessed`); | ||
| }); | ||
| ``` | ||
| This queue detected that a job [stalled](#stalling-jobs). Note that this might not be the same queue _instance_ that processed the job and ultimately stalled; instead, it's the queue _instance_ that happened to _detect_ the stalled job. | ||
| ### Queue PubSub Events | ||
@@ -543,2 +541,40 @@ | ||
| #### Queue#removeJob(jobId, [cb]) | ||
| ```js | ||
| queue.removeJob(3, function (err) { | ||
| if (!err) { | ||
| console.log('Job 3 was removed'); | ||
| } | ||
| }); | ||
| queue.removeJob(3) | ||
| .then(() => console.log('Job 3 was removed')); | ||
| ``` | ||
| Removes a job by its `jobId`. Idempotent. | ||
| This may have unintended side-effect, e.g. if the job is currently being processed by another worker, so only use this method when you know it's safe. | ||
| Returns the `Queue` instance it was called on. | ||
| #### Queue#destroy([cb]) | ||
| ```js | ||
| queue.destroy(function (err) { | ||
| if (!err) { | ||
| console.log('Queue was destroyed'); | ||
| } | ||
| }); | ||
| queue.destroy() | ||
| .then(() => console.log('Queue was destroyed')); | ||
| ``` | ||
| Removes all Redis keys belonging to this queue (see [Under the hood](#under-the-hood)). Idempotent. | ||
| It goes without saying that this should be used with great care. | ||
| Returns the number of keys removed. | ||
| ## Job | ||
@@ -712,2 +748,27 @@ | ||
| #### Job#remove([cb]) | ||
| ```js | ||
| const job = queue.createJob({...}); | ||
| // ... | ||
| job.remove(function (err) { | ||
| if (!err) { | ||
| console.log('Job was removed'); | ||
| } | ||
| }); | ||
| job.remove() | ||
| .then(() => console.log('Job was removed')); | ||
| ``` | ||
| Removes a job from the queue. Idempotent. | ||
| This may have unintended side-effect, e.g. if the job is currently being processed by another worker, so only use this method when you know it's safe. | ||
| Note that this method will call [`Queue#removeJob`](#queueremovejobjobid-cb) with the job id, so if you don't have the job in memory, but knows its id, it's much more efficient to use `Queue#removeJob` instead of getting the job first. | ||
| Returns the `Job` instance it was called on. | ||
| ### Defaults | ||
@@ -714,0 +775,0 @@ |
New alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Fixed alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
New author
Supply chain riskA new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package.
Found 1 instance in 1 package
Improved metrics
- Total package byte prevSize
- increased by6.12%
85578
- Number of package files
- increased by5.26%
20
- Lines of code
- increased by8.47%
1178
- Number of lines in readme file
- increased by8.08%
816
- Number of medium supply chain risk alerts
- decreased by-100%
0
No dependency changes