npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

distributed-callback-queue

v2.1.0

Published

Creates distributed callback queue based on redis pubsub. Pass 2 redis clients (supports redis sentinel as well for HA), manages locks across multiple processes

Downloads

14

Readme

Distributed callback queue

Codacy Badge

Purpose of this module to allow only 1 similar action to run at the same time across any amount of the machines. This task is solved by the means of acquiring lock before any action is performed. Currently redis is used as a backing provider, which is super fast, and more than reliable for this task, especially when combined with redis-sentinel, or cluster in the future (once it's production ready).

This library requires you to pass 2 redis instances: 1 will be used for acquiring and releasing locks and the other one for pubsub events (and this is how the system becomes distributed)

npm install distributed-callback-queue -S

Notice

Because nodejs errors do not have own enumerable properties, and we still want stack-traces, messages, and other fancy stuff, this module uses error-tojson, which makes properties of error objects enumerable. Therefore, make sure you do not include circular references in the error object, as it will kill your process

Usage

Opts description

var CallbackQueue = require('distributed-callback-queue');

// assume we have 2 redis clients ready
// one called `redis` and the other `pubsub`. They must be different clients
// technically they can even connect to different redis instances machines,
// since they are used for 2 separate tasks

var opts = {
    client: redis,  // lock acquisition, can be shared with the rest of the app
    pubsub: pubsub, // pubsub, please do not share unless you know what you are doing
    pubsubChannel: '{mypubsubchannel}',
    lock: {
        timeout: 20000, // in 20000ms lock will expire, defaults to 10000
        retries: 0, // if we failed to acquire lock for the first time, retry in `delay`. Defaults to 1
        delay: 500 // retry in 500 ms when acquiring new lock. Default: 100
    },
    lockPrefix: '{mylockprefix}', // used for prefixing keys in redis and in local queue, defaults to {dcb}
    log: false // turn of logging
};

var callbackQueue = new CallbackQueue(opts);

/**
 * Method push
 * Accepts following arguments:
 * `id` {String} identificator of the job. Unique across processes between same lockPrefix
 * `onJobcompleted` {Function} called when job has been completed or failed
 * `onJobQueued` {Function} called after `onJobCompleterd` has been added to queue
 */
callbackQueue.push('jobid', onJobCompleted, onJobQueued);

/**
 * Will be called once job had been completed
 * This function will be called for every queued callback
 */
function onJobCompleted(err, arg1, arg2, ..., argN) {
    if (err) {
        // first arg is canonical error
        // you decide what the rest of args are, but make sure that first one
        // is an error
        return console.error('Failed to complete job: ', err);
    }

    // equals 10
    console.log(arg1);
}

/**
 * This function is called once lock has either failed to be acquired or
 * was acquired. In case of the latter, we need to perform our desired job here
 * @param {Errir}   err
 * @param {Boolean|Function} workCompleted
 */
function onJobQueued(err, workCompleted) {
    if (err) {
        // smth gone wrong - maybe redis is down, onJobCompleted will be called with this error
        return;
    }

    if (!workCompleted) {
        // someone else has the lock, don't do anything
        return;
    }

    // I've got the lock, do something
    var nastylongcalculations = 1 + 1;

    workCompleted(null, nastylongcalculations);
}