[Backgroundrb-devel] new BackgroundRB

Ezra Zygmuntowicz ezmobius at gmail.com
Mon Oct 30 16:33:11 EST 2006


Hey Greg-


	Yes I am sorry, the new architecture uses fork and named pipes and a  
bunch of unix stuff to do its magick. Now you may be able to port it  
to qwork on windows, but I don't think it is possible :( I'm really  
sorry about this but I need this thing to be as robust and solid as  
it can be and in the end windows isn't compatible. Now you may be  
able to still work locally by installing cygwin and running the  
backgroundrb under cygwin.


Cheers-
-Ezra


On Oct 30, 2006, at 10:09 AM, Rockin' wrote:

> Ezra,
>
>
>
> Thanks for all your efforts on this.  I love BackgroundRb – it is  
> super useful.
>
>
>
> I’m interested in porting to the new version, but my primary  
> development platform is Windows.  (Although I deploy to FC5.)
>
> I can’t afford to break my existing stuff right now, however, I do  
> think the new architecture will solve many of my current problems  
> and would like to make the switch.
>
>
>
> What will I run into on Windows?  I don’t care if certain things  
> are more cumbersome, like start/stop/restart.  But I do care if it  
> flat out doesn’t work because the way that process forking is done  
> is OS-specific or something.  As I mentioned, I don’t have time for  
> that tangent right now, otherwise, I’d be happy to try it and even  
> help out with its development.
>
>
>
> What is your advice?
>
>
>
> Thanks!
>
>
>
> -greg
>
>
>
> =======================
>
>
>
> Subject: [Backgroundrb-devel] [ANN] BackgrounDRb 0.2.0 Release!
>
>       Complete    rewrite.
>
> To: BackgroundRb ML <backgroundrb-devel at rubyforge.org>,
>
>       rubyonrails-talk at googlegroups.com
>
> Message-ID: <F1FA91DA-6CA5-47EF-9BA9-83ECF66A7F56 at gmail.com>
>
> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes;
>
>       format=flowed
>
>
>
> 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)
>
>
>
>

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