Are you happy with your logging solution? Would you help us out by taking a 30-second survey? Click here


RabbitMQ JRuby based worker framework on top of march_hare (hot_bunnies)

Subscribe to updates I use frenzy_bunnies

Statistics on frenzy_bunnies

Number of watchers on Github 68
Number of open issues 6
Main language Ruby
Average time to merge a PR 5 days
Open pull requests 2+
Closed pull requests 3+
Last commit about 5 years ago
Repo Created about 7 years ago
Repo Last Updated almost 2 years ago
Size 428 KB
Organization / Authorjondot
Page Updated
Do you use frenzy_bunnies? Leave a review!
View open issues (6)
View frenzy_bunnies activity
View on github
Fresh, new opensource launches 🚀🚀🚀
Trendy new open source projects in your inbox! View examples

Subscribe to our mailing list

Evaluating frenzy_bunnies for your project? Score Explanation
Commits Score (?)
Issues & PR Score (?)


A lightweight background workers library based on JRuby and the very efficient march_hare RabbitMQ driver for very fast and efficient processing.

Unlike other background job processing libraries, a Frenzy Bunnies worker is offering its work to a native JVM-based thread pool, where threads are allocated and cached.

This firstly means that the processing model isn't process-per-worker (saving memory) and it also isn't fixed-thread-per-worker based allowing workers to be pooled(saving memory even further).

RabbitMQ is a really awesome queue solution for background jobs as well as more real-time messaging processing. Within its strengths are its performance, portability - almost every worthy server-side language and platform has a RabbitMQ driver and you're not limited to process on a single platform, and high-availability out of the box (as opposed to Redis, although Sentinel is quite a progress - hurray!).

Here are great background slides given by Paolo Negri over Rails Underground 2009 about RabbitMQ.

Quick Start

Add this line to your application's Gemfile:

gem 'frenzy_bunnies'

And then execute:

$ bundle

Or install it yourself as:

$ gem install frenzy_bunnies

Then, you basically just need to define a worker in its own class, and then decide if you want to use the Frenzy Bunnies runner frenzy_bunnies to run it, or do it programmatically via the FrenzyBunnies::Context API.

class FeedWorker
  include FrenzyBunnies::Worker
  from_queue 'new.feeds', :prefetch => 20, :threads => 13, :durable => true

  def work(msg)
    puts msg

You indicate that a class is a worker by include FrenzyBunnies::Worker. Set up a queue with from_queue and implement a work(msg) method.

You should indicate successful processing with ack!, otherwise it will be rejected and lost (per RabbitMQ semantics, in future versions, they'll add a feature where rejected messages goes to an error queue).

Running with CLI

Running a worker with the command-line executable is easy

$ frenzy_bunnies start_workers worker_file.rb

Where worker_file.rb is a file containing all of your worker(s) definition. FrenzyBunnies will require the file and immediately start handing work to your workers.

Running Programatically

Assuming that workers are already required in your code, their classes should be visible by the moment you write this code:

f = FeedWorker, FeedDownloader

In the listing above, accepts your worker classes, and will run your workers immediately.

Web Dashboard

When FrenzyBunnies run, it will automatically create a web dashboard for you, on localhost:11333 by default.

Currently, the dashboard displays your job statistics (passed vs. failed), JVM health (heap usage) and threads overview.

Changing the bound address is easy to do through the many options you can pass to the running Context:

f = :web_host=>'', :web_port=>11222

context definitions

In Detail

Worker Configuration

In your worker class, say from_queue 'queue_name' and pass any of these options:

:exchange # default frenzy_bunnies. name of exchange.
:exchange_type # default :direct. type of exchange used.
:routing_key # default queue_name. allows for other routing keys, useful for topic exchanges.
:prefetch  # default 10. number of messages to prefetch each time
:durable   # default false. durability of the queue
:timeout_job_after # default 5. reject the message if not processed for number of seconds
:threads  # default none. number of threads in the threadpool. leave empty to let the threadpool manage it.


class FeedWorker
  include FrenzyBunnies::Worker
  from_queue 'new.feeds', :prefetch => 20, :threads => 13, :durable => true


General Configuration

Global / running configuration can be set through the running context FrenzyBunnies::Context, pass any of these as options (shown with defaults).

:host       # default 'localhost'
:heartbeat  # default 5
:web_host   # default 'localhost'
:web_port   # default 11333
:web_threadfilter # default /^pool-.*/
:env        # default ''

Example: :heartbeat => 10

AMQP Queue Wiring Under the Hood

If you're interested with the mechanics, in order to mimic a background-job / work-queue semantics, the following is the AMQP wireup used within this library:

  • Durable per configuration
  • The exchange is created and named by default frenzy_bunnies
  • Each worker is bound to an AMQP queue named my_queue_environment with the environment postfix appended automatically.
  • The routing key on the exchange is of the same name and bound to the queue.


Fork, implement, add tests, pull request, get my everlasting thanks and a respectable place here :).


Copyright (c) 2012 Dotan Nahum @jondot. See MIT-LICENSE for further details.

frenzy_bunnies open issues Ask a question     (View All Issues)
  • about 4 years Rails wrapper
  • over 4 years Outdated on Ruby Gems
  • about 5 years concurrency isn't working ?
  • over 5 years Add ability to define routing key
frenzy_bunnies open pull requests (View All Pulls)
  • Allows to set parameter `vhost` when creating a Context
  • [#3] Add ability to define routing key
frenzy_bunnies list of languages used
Other projects in Ruby