[Backgroundrb-devel] [ANN] Update

Ezra Zygmuntowicz ezmobius at gmail.com
Tue Aug 1 14:59:16 EDT 2006


	OK there is a new release with some new features in it. The  
delete_worker method has been refactored to make sure it works with  
all kinds of workers(thanks Ben Johnson). I touched up the code in  
quite a few places. I also split the MiddleMan class and the  
BackgrounDRb::Rails class into their won files since they were  
getting bigger.

	Michael Siebert sent some nice patches that have been applied as  
well. Support for starting workers when the drb server starts up  
based on config file options and also cron style workers with  
repeating tasks.


You can now have workers that autostart when the drb server is  
started, and you can also
have cron like workers that run at intervals. To specify a worker to  
startup when the
drb server does you can add something liek this to your  
backgroundrb.yml config file:

     class: foo_worker
     args: bar

Change job_key to be the actual named key you want to use for this  
autostart worker.
In you workers you can now have timed tasks that repeat themselves at  
intervals that you set.
A simple example looks like this:

class CronWorker <BackgrounDRb::Rails

   repeat_every 10.minutes
   first_run Time.now

   def do_work(args)
     @progress ||= 0
     @progress += 1

   def progress

repeat_every takes anything that can be made into a Time object via  
Time.parse. Same
thing with first_run. You can use all the nice rails active support  
time methods in these
declarations like 2.hours and friends.

	Michael- I changed the method names for the cron style workers to  
something I like a little bit better. So make sure you change your  
workers that use the cron stuff to the new syntax.


	I am working on a RindaRing server implementation in order to spread  
load between multiple drb servers at once. This allwos for multiple  
drb servers to easily find each other and share workers. Kind of like  
DNS for drb. This way if you have a really burly task you can run it  
in it's own ruby process without having to use threading and compete  
with other threaded workers for cpu time. This will be a major  
overhaul of how things work so it might be released as a separate  
plugin, not sure yet though.


More information about the Backgroundrb-devel mailing list