[Backgroundrb-devel] pre-release version of backgroundrb available now from svn

hemant gethemant at gmail.com
Fri Nov 2 06:26:44 EDT 2007


On 11/2/07, hemant <gethemant at gmail.com> wrote:
> Hi,
>
> A pre-release version of backgroundrb is available now from svn.
> Download it from here:
>
> http://svn.devjavu.com/backgroundrb/branches/version099/
>
> Since this release marks significant migration from existing
> practices, i intend to keep trunk untouched for a while.
>
> There are no install scripts, but you should copy "backgroundrb" file
> from script directory of plugin to script directory of rails. You
> should also config "backgroundrb.yml" file from config directory of
> plugin to config directory of rails root.
>
> There is one sample worker available in
> BACKGROUNDRB_ROOT/sample_worker directory.
> There is also a sample client available.
>
> Currently, passing of ActiveRecord objects is not supported. Although,
> We can do that, but in most situations, passing 'id' of object is
> enough i thought. Also, you may encounter some bugs when you are
> passing large objects around.
>
> I will try to explain meat of a sample worker:
>
> class FooWorker < MetaWorker
>   set_worker_name :foo_worker
>   attr_accessor :count
>   def worker_init
>     puts "Starting Foo Worker"
>     add_periodic_timer(4) { increment_status}
>   end
>   def process_request p_data
>     p p_data
>   end
>
>   def increment_status
>     @count ||= 0
>     @count += 1
>     register_status(@count)
>   end
> end
>
> First, I intend to wrap MetaWorker within a namespace(read module), so
> pardon me there.
>
> So, when backgroundrb starts it reads all the workers in
> WORKER_ROOT(which should be RAILS_ROOT/lib/workers) directory and
> worker_init is called in child process of each worker. You can use
> worker_init for initializing a worker.
>
> "process_request" is the method which will be normally invoked when
> you receive requests from rails. But there is a exception, in each
> worker there is a method called "register_status" available, which can
> be invoked from workers to register their status with master.
>
> Now, from rails, you can query status of a worker using
>
> MiddleMan.ask_status(:worker => :foo_worker)
>
> All the status requests are server by master itself and hence
> "process_request" inside worker will not be invoked for them.
>
> You will find support for schedules very rough around the edges.
> Reason is, You can use
>
> add_periodic_timer(5) { foo_job }
>
> to do any kind of scheduling. add_periodic_timer takes number of
> seconds as argument.
> for one shot timers, you can use:
>
> add_timer(5) { foo_job }
>
>
> Core of new version of bdrb is implemented on a networking library
> called "packet".  It needs its own introduction. But now, inside each
> worker you can start evented network connections. You have some
> methods like:
>
> connect("localhost",5678,FooHandler)
> start_server("localhost"m,5678,FooServer)
>
> inside each worker, which can be used to let workers do fancy stuff.
> This is just a by product of using "packet" library.
>
> I know, thing is rough around the edge and needs more polish. But
> still, i hope it will be more stable than previous versions of
> backgroundrb.
>
> Please report all the bugs here.
>

Couple of things, I wanted to add.

If you want to access your workers from other machines, then ip
section in config file should be something thats accessible from all
machines.

Also, you can't restart your workers from rails. Although I would like
to have support for starting and stopping of workers dynamically, but
it was possible in this release.

I am looking for suggestions on how to smoothen scheduling of worker
methods. Currently its just add_periodic_timer and whatever we
implement is just going to be "sugar" around it, yet I need some
opinions.


-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org


More information about the Backgroundrb-devel mailing list