Giter VIP home page Giter VIP logo

fairy's Introduction

build status

Redis Queue Battles Message Groups!

Fairy is a lightweight queue engine for node.js based on Redis. Fairy offers ActiveMQ's message groups alike feature which can guarantee the sequential processing order of tasks belong to a same group.

But, unlike message groups, Fairy doesn't always route tasks of a group to a same worker, which will introduce unwanted waiting time when:

  1. Tasks of group X and Y are appointed to worker A.
  2. Worker A is processing tasks of group X sequentially.
  3. Tasks of group Y are pending, while:
  4. Worker B is still idling because of 1.

Fairy will route the task of group Y to worker B in this scenario.

Fairy takes a different approach than Message Groups. Instead of making all tasks of a same group be routed to the same consumer, Fairy route a task to any worker when there's no processing tasks of the same group.

The design philosophy makes Fairy ideal for the following requirements:

  • Tasks of a same groups need be processed in sequence.
  • Each worker processes tasks in serial.
  • Multiple workers need be instantiated to increase throughput.

Fairy takes a different approach than Message Groups. Instead of making all tasks of a same group be routed to the same consumer, Fairy route a task to any worker when there's no processing tasks of the same group.

When the number of workers is much smaller compared to the number of groups, Fairy's approach makes sense.

Resque cannot guarantee the processing order of the tasks although the task queue is FIFO. The more workers you have, the more possible you'll encountering concurrency which breaks the processing order of tasks in the same group.

Installation

npm install fairy

Get Started

The minimium set of APIs you need to learn in order to implement a task queue system are:

  • enqueue tasks, and
  • regist a function for processing them.

Enqueue Tasks

Provide as many parameters as you want (and an optional callback function). The first argument will be used for message grouping.

queue = require('fairy').connect().queue('task_name')
queue.enqueue 'foo', 'bar', ->
  console.log 'your order has been placed, sir.'

Register Task Handler

When registered a task handler, the Fairy queue becomes a worker automatically.

The registered handler function will be called when there're tasks to be processed, with the enqueued parameters of the task. The last argument will be a non-optional callback function.

Arguments of the callback function follow node.js error handling convention: err and res.

Calling the callback function is your responsibility (or Fairy will not dispatch tasks to the worker and block tasks of the same group forever!)

queue = require('fairy').connect().queue('task_name')
queue.regist (param1, param2, callback) ->
  # Do your work here, be it synchronous or asynchronous.
  callback err, res

Web Front-End

Fairy comes with a ready-to-use web front-end. Simply insert the middleware into the pipeline:

app = require('express').createServer()
fairy_web = require 'fairy/web'
app.use fairy_web.connect().middleware
app.listen 3000

More APIs

More APIs include:

  1. Objects of Class Queue:
  • Placing tasks -- enqueue
  • Regist handlers -- regist
  • Reschedule tasks -- reschedule
  • Query status --
    • recently_finished_tasks
    • failed_tasks
    • blocked_groups
    • slowest_tasks
    • processing_tasks
    • workers
    • statistics, etc.
  1. Objects of Class Fairy:
  • queues, return all queues.
  • statistics, return statistics of all queues.

See Example Folder for demos. Or review the Annotated Source Code for complete API explanations.

License

Copyright (c) 2012 Baoshan Sheng

Released under the MIT license.

fairy's People

Contributors

baoshan avatar henryoswald avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fairy's Issues

Tasks seem to be executed multiple times

I need to build a distributed worker system where a group's tasks are worked in serial fashion. This module looks to be exactly what I need; however, I am running into a problem where it looks like the task is being passed to the worker multiple times. Is this a known issue and if I were to spend the time to code an example, is this code active so that the issue can be fixed quickly?

Thanks,
-Dan

null issue

TypeError: Cannot read property '1' of null
at /root/cme/node_modules/fairy/lib/fairy.js:461:36
at /root/cme/node_modules/fairy/node_modules/redis/index.js:1077:13
at try_callback (/root/cme/node_modules/fairy/node_modules/redis/index.js:532:9)
at RedisClient.return_reply (/root/cme/node_modules/fairy/node_modules/redis/index.js:614:13)
at ReplyParser. (/root/cme/node_modules/fairy/node_modules/redis/index.js:266:14)
at ReplyParser.EventEmitter.emit (events.js:95:17)
at ReplyParser.send_reply (/root/cme/node_modules/fairy/node_modules/redis/lib/parser/javascript.js:300:10)
at ReplyParser.execute (/root/cme/node_modules/fairy/node_modules/redis/lib/parser/javascript.js:211:22)
at RedisClient.on_data (/root/cme/node_modules/fairy/node_modules/redis/index.js:488:27)
at Socket. (/root/cme/node_modules/fairy/node_modules/redis/index.js:82:14)
at Socket.EventEmitter.emit (events.js:95:17)
at Socket. (stream_readable.js:746:14)
at Socket.EventEmitter.emit (events.js:92:17)
at emitReadable
(_stream_readable.js:408:10)
at emitReadable (_stream_readable.js:404:5)
at readableAddChunk (_stream_readable.js:165:9)

the 'uncaughtException' handler exits with a success error code (0)

Node normally exits with a non-zero error code when it crashes due to an exception, but the Fairy clean up code calls process.exit(), which then exists with a zero status code. I'm not sure what the appropriate exit code should be, (Node.js seems to use 8 in my preliminary testing) but it definitely shouldn't be zero.

Locking queues

We've been using Fairy in production for a while now, and one of the problems that we keep running into is that we end up with a bunch of FAIRY:QUEUE:* keys in our Redis database that aren't being processed by a worker. Due to the way that Fairy locks the queues, if they contain something, these queues never get processed again and are effectively blocked. I don't know why these queues are getting stuck in the first place, but it could be to do with them not being cleared on a restart, due to a crash, or possibly a Fairy bug (wherever it comes from, I would definitely consider this behaviour a bug though).

I think Fairy could be improved by a more sophisticated and dedicated locking scheme. The Redis documentation comes with a thorough description of how to use SETNX to create a locking mechanism with a timeout. Each queue would have its own lock that would be acquired by a worker when processing the queue. This would then be released when the queue was empty again. This would replace the test of whether the queue already contains entries in the _poll method. Since the lock has a timeout (which could be set by the user depending on the expected length of tasks), even if the queue did get stuck as before, the lock would eventually expire and the queue could be processed again without manual intervention.

Polling vs PubSub

Have you considered using the Redis pub/sub features instead of polling every 5ms? It would help with CPU load quite a bit! The implementation I have in mind is to get rid of the following line at the end of _poll:

setTimeout @_poll, @polling_interval

The polling could then be reactivated by subscribing to a channel like FAIRY:NEW_JOBS:<queue-name> which would be published to whenever queue.enqueue() is called. This way the whole thing would sit idle until there was actually something to do. I believe that the current implementation would then clean out the whole SOURCE queue without needing to poll again, but I could be wrong about this.

Is there a reason you chose polling? Sometimes things that seem like a good idea from the outside are actually avoided for good reasons, so I apologise if that's the case. If you don't have any objections I will likely spend some time converting fairy over to pub/sub rather than polling when I get the time.

(I'm working with @henryoswald on a project that uses fairy, hence the interest from us.)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.