Hello Folks-
I am really happy to announce the release of BackgrounDRb 0.2.0 .
This is a complete rewrite and re-architecture of this codebase. I want
to
thank skaar for all of his hard work. I put out a call for help with the
new
architecture and skaar stepped up bigtime. I had already written the
new
scheduler and cron compatible syntax and moved to multi process
architecture. But he took what I had that wasn’t very whole and did a
whopping 100 svn commits to the project! Big ups to skaar for this
release!
= BackgrounDRb 0.2.0
!! Note that this is in an entirely different svn repo then the old
plugin.
Make sure you remove the old before you install the new.
http://svn.devjavu.com/backgroundrb/tags/release-0.2.0/README
http://svn.devjavu.com/backgroundrb/tags/release-0.2.0 (latest release)
http://svn.devjavu.com/backgroundrb/trunk (svn trunk)
http://backgroundrb.devjavu.com (trac)
http://backgroundrb.rubyforge.org (rdoc)
Copyright (c) 2006 Ezra Z. and skaar[at]waste[dot]org
== DISCLAIMER
The 0.2.0 release of BackgrounDRb is a complete re-write of previous
releases and is to be considered experimental, in-complete and in many
respect untested. Our goal is to reach a release recommended for
production use by 0.3.x. This said, this release is a more robust
solution that the previous release.
Also note that support for Windows is deprecated with this release of
BackgrounDRb, sorry : ( . It may work under cygwin but we have not tried
it.
== Introduction
BackgrounDRb is a ruby job server and scheduler. It main intent is to be
used with Ruby on Rails applications for offloading long running tasks.
Since a rails application blocks while servicing a request it is best
to move long running tasks off into a background process that is
divorced
from the http request/response cycle.
This new release of BackgrounDRb is also modular and can be used without
Rails. So any ruby program or framework can use it.
== Technology Overview
This 0.2.x branch of BackgrounDRb introduces a completely new
architecture
then the previous versions. Instead of a single process, multi
threaded environment,
the new system uses multi process with IPC to manage workers. So each of
your
workers will run in their own ruby interpreter. The interface that you
use within rails remains mostly unchanged.
The new architecture allows for a much more robust system. Each of your
worker classes get run in their own ruby interpreter. The main server
process
holds a collection of references to your running worker objects. This
acts as
the interface or MiddleMan that you use to interact with your remote
jobs from
rails or other ruby client code. When workers are spawned an
interprocess
communication channel is opened between the MiddleMan and the worker.
There is a heartbeat setup between parent and child processes so that if
you kill the parent, all children processes are killed off the next
time they try to
hearbeat. All of this happens transparently to you as a user.
The new release comes with a brand new job scheduler. You can use
simple triggers like repeat_every or you can get more complex and use
full cron compatible syntax.
Workers can be scheduled by two built in ‘trigger’ types. A simple
‘trigger’ is specified with start, stop and interval:
require ‘active_support’
MiddleMan.schedule_worker(
:class => :example_worker,
:job_key => :schedule_test,
:worker_method => :other_method,
:trigger_args => {
:start => Time.now + 5.seconds,
:end => Time.now + 10.minutes,
:repeat_interval => 30.seconds
}
The cron trigger uses a similar syntax to cron found on UNIX systems:
MiddleMan.schedule_worker(
:class => simple_class,
:job_key => :schedule_test,
:worker_method => :arg_method,
:worker_method_args => “my argument to arg_method”,
:trigger_args => “0 15 10 * * * *”
)
Also note that when the server starts up, you will see 3 processes
running.
One of the is the MiddleMan server, one is the results worker and one is
the logger worker. When you do a logger.info(“foo log!”) in your
workers,
you are actually logging to the Logger worker.
As you might imagine, this new way of managing multiple processes will
scale a lot better then the multi threaded single process version 
But
also be aware that there is still a thread pool in the middleman that
you
can control the size of. All this does is keep the plugin from spawning
too
many processes. It will allow however many workers you specify to run at
once and any more then that will just queue up and wit for their turn to
spawn.
If you are already a user of the old BackgrounDRb please give the new
version a tryout. It should not require very much work to port your
worker
classes to the new architecture.
This is alpha software folks. It works for me™ but we will not be held
responsible
if it ruins your day
– Ezra Z.-- Lead Rails Evangelist
– [email protected]
– Engine Y., Serious Rails Hosting
– (866) 518-YARD (9273)
