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)