Skip to content

Latest commit

 

History

History
93 lines (65 loc) · 2.75 KB

README.rdoc

File metadata and controls

93 lines (65 loc) · 2.75 KB

Beetle

High Availability AMQP Messaging with Redundant Queues

About

Beetle grew out of a project to improve an existing ActiveMQ based messaging infrastructure. It offers the following features:

  • High Availability (by using multiple message broker instances)

  • Redundancy (by replicating queues)

  • Simple client API (by encapsulating the publishing/ deduplication logic)

More information can be found on the project website.

Usage

Configuration

# configure machines

Beetle.config do |config|
  config.servers = "broker1:5672, broker2:5672"
  config.redis_server = "redis1:6379"
end

# instantiate a beetle client

b = Beetle::Client.new

# configure exchanges, queues, bindings, messages and handlers

b.configure do |config|
  config.queue :test
  config.message :test
  config.handler(:test) { |message| puts message.data }
end

Publishing

b.publish :test, "I'm a test message"

Subscribing

b.listen_queues

Examples

Beetle ships with a number of example scripts.

The top level Rakefile comes with targets to start several RabbitMQ and redis instances locally. Make sure the corresponding binaries are in your search path. Open four new shell windows and execute the following commands:

rake rabbit:start1
rake rabbit:start2
rake redis:start1
rake redis:start2

Prerequisites

To set up a redundant messaging system you will need

  • at least 2 AMQP servers (we use RabbitMQ)

  • at least one Redis server (better are two in a master/slave setup, see REDIS_AUTO_FAILOVER.rdoc)

Gem Dependencies

At runtime, Beetle will use

For development, you’ll need

Authors

Stefan Kaes, Pascal Friederich, Ali Jelveh and Sebastian Roebke.

You can find out more about our work on our dev blog.

Copyright © 2010 XING AG

Released under the MIT license. For full details see MIT-LICENSE included in this distribution.