beetle 0.1

data/etc/redis-slave.conf

@@ -0,0 +1,189 @@
+# Redis configuration file example
+
+# By default Redis does not run as a daemon. Use 'yes' if you need it.
+# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
+daemonize no
+
+# When run as a daemon, Redis write a pid file in /var/run/redis.pid by default.
+# You can specify a custom pid file location here.
+pidfile ./tmp/redis-slave.pid
+
+# Accept connections on the specified port, default is 6379
+port 6380
+
+# If you want you can bind a single interface, if the bind option is not
+# specified all the interfaces will listen for connections.
+#
+# bind 127.0.0.1
+
+# Close the connection after a client is idle for N seconds (0 to disable)
+timeout 300
+
+# Set server verbosity to 'debug'
+# it can be one of:
+# debug (a lot of information, useful for development/testing)
+# notice (moderately verbose, what you want in production probably)
+# warning (only very important / critical messages are logged)
+loglevel debug
+
+# Specify the log file name. Also 'stdout' can be used to force
+# the demon to log on the standard output. Note that if you use standard
+# output for logging but daemonize, logs will be sent to /dev/null
+logfile stdout
+
+# Set the number of databases. The default database is DB 0, you can select
+# a different one on a per-connection basis using SELECT <dbid> where
+# dbid is a number between 0 and 'databases'-1
+databases 16
+
+################################ SNAPSHOTTING  #################################
+#
+# Save the DB on disk:
+#
+#   save <seconds> <changes>
+#
+#   Will save the DB if both the given number of seconds and the given
+#   number of write operations against the DB occurred.
+#
+#   In the example below the behaviour will be to save:
+#   after 900 sec (15 min) if at least 1 key changed
+#   after 300 sec (5 min) if at least 10 keys changed
+#   after 60 sec if at least 10000 keys changed
+save 900 1
+save 300 10
+save 60 10000
+
+# Compress string objects using LZF when dump .rdb databases?
+# For default that's set to 'yes' as it's almost always a win.
+# If you want to save some CPU in the saving child set it to 'no' but
+# the dataset will likely be bigger if you have compressible values or keys.
+rdbcompression yes
+
+# The filename where to dump the DB
+dbfilename dump.rdb
+
+# For default save/load DB in/from the working directory
+# Note that you must specify a directory not a file name.
+dir ./tmp/slave/
+
+################################# REPLICATION #################################
+
+# Master-Slave replication. Use slaveof to make a Redis instance a copy of
+# another Redis server. Note that the configuration is local to the slave
+# so for example it is possible to configure the slave to save the DB with a
+# different interval, or to listen to another port, and so on.
+#
+slaveof 127.0.0.1 6379
+
+# If the master is password protected (using the "requirepass" configuration
+# directive below) it is possible to tell the slave to authenticate before
+# starting the replication synchronization process, otherwise the master will
+# refuse the slave request.
+#
+# masterauth <master-password>
+
+################################## SECURITY ###################################
+
+# Require clients to issue AUTH <PASSWORD> before processing any other
+# commands.  This might be useful in environments in which you do not trust
+# others with access to the host running redis-server.
+#
+# This should stay commented out for backward compatibility and because most
+# people do not need auth (e.g. they run their own servers).
+#
+# requirepass foobared
+
+################################### LIMITS ####################################
+
+# Set the max number of connected clients at the same time. By default there
+# is no limit, and it's up to the number of file descriptors the Redis process
+# is able to open. The special value '0' means no limts.
+# Once the limit is reached Redis will close all the new connections sending
+# an error 'max number of clients reached'.
+#
+# maxclients 128
+
+# Don't use more memory than the specified amount of bytes.
+# When the memory limit is reached Redis will try to remove keys with an
+# EXPIRE set. It will try to start freeing keys that are going to expire
+# in little time and preserve keys with a longer time to live.
+# Redis will also try to remove objects from free lists if possible.
+#
+# If all this fails, Redis will start to reply with errors to commands
+# that will use more memory, like SET, LPUSH, and so on, and will continue
+# to reply to most read-only commands like GET.
+#
+# WARNING: maxmemory can be a good idea mainly if you want to use Redis as a
+# 'state' server or cache, not as a real DB. When Redis is used as a real
+# database the memory usage will grow over the weeks, it will be obvious if
+# it is going to use too much memory in the long run, and you'll have the time
+# to upgrade. With maxmemory after the limit is reached you'll start to get
+# errors for write operations, and this may even lead to DB inconsistency.
+#
+# maxmemory <bytes>
+
+############################## APPEND ONLY MODE ###############################
+
+# By default Redis asynchronously dumps the dataset on disk. If you can live
+# with the idea that the latest records will be lost if something like a crash
+# happens this is the preferred way to run Redis. If instead you care a lot
+# about your data and don't want to that a single record can get lost you should
+# enable the append only mode: when this mode is enabled Redis will append
+# every write operation received in the file appendonly.log. This file will
+# be read on startup in order to rebuild the full dataset in memory.
+#
+# Note that you can have both the async dumps and the append only file if you
+# like (you have to comment the "save" statements above to disable the dumps).
+# Still if append only mode is enabled Redis will load the data from the
+# log file at startup ignoring the dump.rdb file.
+#
+# The name of the append only file is "appendonly.log"
+#
+# IMPORTANT: Check the BGREWRITEAOF to check how to rewrite the append
+# log file in background when it gets too big.
+
+appendonly yes
+
+# The fsync() call tells the Operating System to actually write data on disk
+# instead to wait for more data in the output buffer. Some OS will really flush 
+# data on disk, some other OS will just try to do it ASAP.
+#
+# Redis supports three different modes:
+#
+# no: don't fsync, just let the OS flush the data when it wants. Faster.
+# always: fsync after every write to the append only log . Slow, Safest.
+# everysec: fsync only if one second passed since the last fsync. Compromise.
+#
+# The default is "always" that's the safer of the options. It's up to you to
+# understand if you can relax this to "everysec" that will fsync every second
+# or to "no" that will let the operating system flush the output buffer when
+# it want, for better performances (but if you can live with the idea of
+# some data loss consider the default persistence mode that's snapshotting).
+
+# appendfsync always
+appendfsync everysec
+# appendfsync no
+
+############################### ADVANCED CONFIG ###############################
+
+# Glue small output buffers together in order to send small replies in a
+# single TCP packet. Uses a bit more CPU but most of the times it is a win
+# in terms of number of queries per second. Use 'yes' if unsure.
+glueoutputbuf yes
+
+# Use object sharing. Can save a lot of memory if you have many common
+# string in your dataset, but performs lookups against the shared objects
+# pool so it uses more CPU and can be a bit slower. Usually it's a good
+# idea.
+#
+# When object sharing is enabled (shareobjects yes) you can use
+# shareobjectspoolsize to control the size of the pool used in order to try
+# object sharing. A bigger pool size will lead to better sharing capabilities.
+# In general you want this value to be at least the double of the number of
+# very common strings you have in your dataset.
+#
+# WARNING: object sharing is experimental, don't enable this feature
+# in production before of Redis 1.0-stable. Still please try this feature in
+# your development environment so that we can test it better.
+shareobjects no
+shareobjectspoolsize 1024

data/examples/README.rdoc

@@ -0,0 +1,14 @@
+=== Examples
+
+Beetle ships with a number of {example scripts}[http://github.com/xing/beetle/tree/master/examples/].
+
+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
+
+After running the redis_failover.rb script you will need to restart both redis servers.

data/examples/attempts.rb

@@ -0,0 +1,66 @@
+# attempts.rb
+# this example shows you how to use the exception limiting feature of beetle
+# it allows you to control the number of retries your handler will go through
+# with one message before giving up on it
+#
+# ! check the examples/README.rdoc for information on starting your redis/rabbit !
+#
+# start it with ruby attempts.rb
+
+require "rubygems"
+require File.expand_path("../lib/beetle", File.dirname(__FILE__))
+
+# set Beetle log level to info, less noisy than debug
+Beetle.config.logger.level = Logger::INFO
+
+# setup client
+client = Beetle::Client.new
+client.register_queue(:test)
+client.register_message(:test)
+
+# purge the test queue
+client.purge(:test)
+
+# empty the dedup store
+client.deduplication_store.flushdb
+
+# we're starting with 0 exceptions and expect our handler to process the message until the exception count has reached 10
+$exceptions = 0
+$max_exceptions = 10
+
+# declare a handler class for message processing
+# in this example we've not only overwritten the process method but also the
+# error and failure methods of the handler baseclass
+class Handler < Beetle::Handler
+  
+  # called when the handler receives the message - fail everytime
+  def process
+    raise "failed #{$exceptions += 1} times"
+  end
+  
+  # called when handler process raised an exception
+  def error(exception)
+    logger.info "execution failed: #{exception}"
+  end
+  
+  # called when the handler has finally failed
+  # we're stopping the event loop so this script stops after that
+  def failure(result)
+    super
+    EM.stop_event_loop
+  end
+end
+
+# register our handler to the message, configure it to our max_exceptions limit, we configure a delay of 0 to have it not wait before retrying
+client.register_handler(:test, Handler, :exceptions => $max_exceptions, :delay => 0)
+
+# publish a our test message
+client.publish(:test, "snafu")
+
+# and start our listening loop...
+client.listen
+
+# error handling, if everything went right this shouldn't happen.
+if $exceptions != $max_exceptions + 1
+  raise "something is fishy. Failed #{$exceptions} times"
+end

data/examples/handler_class.rb

@@ -0,0 +1,64 @@
+# handler.rb
+# this example shows you how to create a simple Beetle::Handler to process your messages
+#
+#
+# 
+# ! check the examples/README.rdoc for information on starting your redis/rabbit !
+#
+# start it with ruby handler_class.rb
+
+require "rubygems"
+require File.expand_path("../lib/beetle", File.dirname(__FILE__))
+
+# set Beetle log level to info, less noisy than debug
+Beetle.config.logger.level = Logger::INFO
+
+# setup client
+client = Beetle::Client.new
+client.register_queue(:test)
+client.register_message(:test)
+
+# purge the test queue
+client.purge(:test)
+
+# empty the dedup store
+client.deduplication_store.flushdb
+
+# setup our counter
+$counter = 0
+
+# declare a handler class for message processing
+# this is a very basic example, subclass your own implementation
+# process is the only method required and the message accessor is
+# already implemented - see message.rb for more documentation on what you
+# can do with it
+class Handler < Beetle::Handler
+
+  # called when the handler receives the message
+  def process
+    i = message.data.to_i
+    logger.info "adding #{i}"
+    $counter += i
+  end
+
+end
+
+# register our handler to the message
+client.register_handler(:test, Handler)
+
+# publish 10 test messages
+message_count = 10
+published     = 0
+message_count.times {|i| published += client.publish(:test, i) } # publish returns the number of servers the message has been sent to
+puts "published #{published} test messages"
+
+# start our listening loop and stop it with a timer -
+# the 0.1 figure should be well above the time necessary to handle
+# all 10 messages
+client.listen do
+  EM.add_timer(0.1) { client.stop_listening }
+end
+
+# the counter should now be message_count*(message_count-1)/2 if it's not something went wrong
+puts "Result: #{$counter}"
+raise "something is fishy" unless $counter == message_count*(message_count-1)/2

data/examples/handling_exceptions.rb

@@ -0,0 +1,73 @@
+# handling_exceptions.rb
+# this examples shows you how beetle retries and exception handling works in general
+# as you will see in the Beetle::Handler example every message will raise an exception
+# once and be succesful on the next attempt, the error callback is called on every process
+# exception
+# ! check the examples/README.rdoc for information on starting your redis/rabbit !
+#
+# start it with ruby attempts.rb
+
+require "rubygems"
+require File.expand_path("../lib/beetle", File.dirname(__FILE__))
+
+# set Beetle log level to info, less noisy than debug
+Beetle.config.logger.level = Logger::INFO
+
+# setup client
+client = Beetle::Client.new
+client.register_queue(:test)
+client.register_message(:test)
+
+# purge the test queue
+client.purge(:test)
+
+# empty the dedup store
+client.deduplication_store.flushdb
+
+# setup our counter
+$completed = 0
+
+# declare a handler class for message processing
+# handler fails on the first execution attempt, then succeeds
+class Handler < Beetle::Handler
+
+  # called when the handler receives the message, fails on first attempt
+  # succeeds on the next and counts up our counter
+  def process
+    raise "first attempt for message #{message.data}" if message.attempts == 1
+    logger.info "processing of message #{message.data} succeeded on second attempt. completed: #{$completed+=1}"
+  end
+
+  # called when handler process raised an exception
+  def error(exception)
+    logger.info "execution failed: #{exception}"
+  end
+
+end
+
+# register our handler to the message, configure it to our max_exceptions limit, we configure a delay of 0 to have it not wait before retrying
+client.register_handler(:test, Handler, :exceptions => 1, :delay => 0)
+
+# publish 10 test messages
+n = 0
+10.times { |i| n += client.publish(:test, i+1) } # publish returns the number of servers the message has been sent to
+puts "published #{n} test messages"
+
+# start the listening loop
+client.listen do
+  # catch INT-signal and stop listening
+  trap("INT") { client.stop_listening }
+  # we're adding a periodic timer to check wether all 10 messages have been processed without exceptions
+  timer = EM.add_periodic_timer(1) do
+    if $completed == n
+      timer.cancel
+      client.stop_listening
+    end
+  end
+end
+
+puts "Handled #{$completed} messages"
+if $completed != n
+  raise "Did not handle the correct number of messages"
+end
+

data/examples/multiple_exchanges.rb

@@ -0,0 +1,48 @@
+# multiple_exchanges.rb
+# this example shows you how to create a queue that is bound to two different exchanges
+# we'll create the queue foobar and bind it to the exchange foo and the exchange bar with different
+# routing keys (info tidbit: different exchanges allow better loadbalacing on multi-core machines)
+# your handler will then receive messages from both exchanges
+# ! check the examples/README.rdoc for information on starting your redis/rabbit !
+#
+# start it with ruby multiple_exchanges.rb
+
+require "rubygems"
+require File.expand_path("../lib/beetle", File.dirname(__FILE__))
+
+# set Beetle log level to info, less noisy than debug
+Beetle.config.logger.level = Logger::INFO
+
+# setup client
+client = Beetle::Client.new
+
+# create two exchanges
+client.register_exchange(:foo)
+client.register_exchange(:bar)
+
+# create a queue foobar bound to the exchange foo with the key foo
+client.register_queue(:foobar, :exchange => :foo, :key => "foo")
+# create an additional binding for the foobar queue, this time to the bar exchange and with the bar key
+client.register_binding(:foobar, :exchange => :bar, :key => "bar")
+
+# register two messages foo and bar remember that the defaults for exchange and key is the message name
+client.register_message(:foo)
+client.register_message(:bar)
+
+# declare a handler class for message processing
+# this one just gives us a debug output
+client.register_handler(:foobar) do |message|
+  puts "handler received: #{message.data}"
+end
+
+# and publish our two messages
+client.publish(:foo, "message from foo exchange")
+client.publish(:bar, "message from bar exchange")
+
+# this starts the event machine event loop using EM.run
+# stop listening after 0.1 seconds this should be more than enough time
+# to finish processing our messages
+client.listen do
+  EM.add_timer(0.1) { client.stop_listening }
+end
+