BackgrounDRb 0.2.0 Release. Complete Rewrite

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 :wink: 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 :wink:

-- Ezra Zygmuntowicz-- Lead Rails Evangelist
-- ez@engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

This is alpha software folks. It works for me™ but we will not be held
responsible
if it ruins your day :wink:

I use your Scheduler/Trigger but its fired only once:

the worker is started like this:
  def start_worker
    MiddleMan.schedule_worker(
    :class => :firewall_worker,
    :job_key => :worker,
    :trigger_args => {
      :start_time => Time.now + 10.seconds,
      :repeat_interval => 10.seconds,
      :trigger_type => :trigger
    })
    render :nothing => true
    end

and its defined like this:

class FirewallWorker < BackgrounDRb::Worker::RailsBase

  def do_work(args)
    logger.info("hello outside world")
  end

end

As I understand the README this should be enough to trigger the worker
periodically.

I'm at Revision 123

The scheduler is currently broken. We will be pushing a 0.2.1 release
tonight or tomorrow that fixes it.

-Ezra

if it ruins your day :wink:

it did...

it works if :worker_method and :worker_method_args are defined
schedule_worker seems to handle the default :do_work badly.

Define badly. Anyways, please grab a new copy from trunk instead of
the release tag. There has been more work done on the scheduler and
we are close to another release to remedy the issues.

-Ezra