[Backgroundrb-devel] [ANN] BackgrounDRb 0.2.0 Release! Complete rewrite.

Ezra Zygmuntowicz ezmobius at gmail.com
Sun Oct 29 20:40:46 EST 2006


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 Zygmuntowicz 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 Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)






More information about the Backgroundrb-devel mailing list