similar to: Reusable workers

I installed BackgrounDRB as instructed: script/plugin install svn://rubyforge.org//var/svn/backgroundrb rake backgroundrb:setup I started it with: rake backgroundrb:start In a model I make the call: MiddleMan.new_worker :class => :rss_worker In /lib/workers I have file rss_worker.rb, which contains the class: Class RssWorker < BackgrounDRb::Rails def do_work(args) ... end end

1. Whenever you ask BackgrounDRb to perform a particular task using: MiddleMan.ask_work(:worker => :rss_worker,:worker_method => :fetch_url, :data => "www.google.com") Your task would be performed then and there. But, if your worker is busy, task won''t be queued, except in socket buffer. And your request may get lost. This isn''t generally a problem

Hello, We are working on a centralized report generating project, which calls for data processing on different servers and then centralizes the reports into a single project. What we would like to do is have a Monitor BackgrounDRb worker call another BackgrounDRb worker to process data on a different server, and then have our Monitor Worker collect the data and then store it according to our

Hi Has anyone mocked a call like the following for backgroundrb? MiddleMan.new_worker(:class => :admin_email_worker, :args => params [:email]) I cannot seem to find the correct manner to do it. Would have liked to be able to do MiddleMan.should_receive (:new_worker).with(:class => :admin_email_worker, :args => {"body" => "my message"}) Cheers Shane

I''ve got some workers that I want to have running all the time. Right now I''m just launching them manually, by requesting a special page in my rails app that includes lines like: MiddleMan.new_worker(:class=> :receiver, :job_key=>:r, :args=>{:sleep_time=>10}) This strikes me as a really weak way to fire up my workers. I basically want to automate things so

Hello all, We''re currently running version .1.x in our environment. We would like to move to .2.x to take advantage of some of the improvements made running in a multi-process environment. We deploy to a linux environment but develop locally in Windows. I''m aware that a number of people have reported the ability to run .2.x of backgroundrb inside cygwin, and for the most part,

for some strange reason this error occours when i create one worker from another BUT only when i derive worker class from Worker::Base instead or Worker::RailsBase - when change it back it works fine, child worker can have empty do_work, but this error still ocours Bad file descriptor (Errno::EBADF) /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:214:in `for_fd''

Hi, Does it make sense to test a worker class by calling Middleman.new_worker? Or should I just be testing the functionality in the do_work method, with, say, a mock object. This seems like a really ugly DRY violation: you''d need to keep the code in the mock and the real worker in sync. That''s the philosophical half of my question. In fact, until someone tells me why I

On Sep 14, 2006, at 10:25 AM, Michael Siebert wrote: > Hey Ezra, > how is the status of your worker pool? i need some thing like this > ASAP and i can''t get David Lemstra''s QueueWorker to work, so: whats > the status? do you have some "beta" lying around on your hard > drive? I dont want to spend my time on that if you''re coming up >

I figured out that in the backgroundrb.yml, I had the old setting of making the database RAILS_ENV. It wasn''t a valid variable in backgroundrb 0.2.1, and it wasn''t reporting an error, so I had no idea. Once I changed it to ''development'' or ''production'', it started working. I found that if a worker has an error, it usually logs the error

I have a job that I am starting from a Rails controller in production mode using MiddleMan: MiddleMan.new_worker(:class => :import_ccg_category_worker, :args => { :category_id => @category.id, :remote_category_id => params[:remote_category_id], :description => "Importing CCG products for #{@ category.name}" }) Both of the category ID variables are just basic integers. I

Hi everyone, I''ve a class that try to spawn two workers, every 5 seconds. The code is something like: while true do MiddleMan.new_worker(:class => :researches_worker,:job_key => :researches) MiddleMan.new_worker(:class => :products_worker,:job_key => :products) sleep(5) end I''m using ":job_key", so if a worker hasn''t already ended its work

Hi, I''m a long time backgroundrb user, still stuck using the very ancient original version from Ezra (not even Ezra''s 2.0 version, I''m using the one that didn''t really have a version number). The 2.0 version did very little but crash for me. Anyway I finally got some time set aside to try out this new version you all have been developing.

Hey there bdrb''ers! I have been so very busy with http://engineyard.com that I have not had time to complete the new release of backgroundrb. But I have done substantial work towards it. It is basically an entirely new beast with a complete rethinking of how it works. I have put up a zip file of the new code base in the hopes that some folks will be able to start playing with

I''m just getting started with backgroundRb and have run into a bit of problem... I want to have my controller launch one worker which in turn launches multiple child workers. When trying to use MiddleMan.new_worker in the parent worker I get a "recycled object" error. Is it not possible to launch workers from within another worker? TIA, for any help. - Jordan Glasner

Hi, I was just creating some new workers (MiddleMan.new_worker) with the same job_key. The first worker for a given key is created correctly. Any subsequent requests to create and greeted with the ''connection closed'' error. I realise that it''s not possible to have two workers with the same key, but maybe a friendlier error message is in order. Chris

Hi all, I need some help with this setup I am trying to get working with BackgrounDRb: An autostarted "dispatcher" worker runs every minute and polls some table for jobs that need to be run at that time. For each job found, the "dispatcher" spawns a "runner" worker that runs the job. So in my "dispatcher" worker, I have some code like this:

Friends- I''m happy to annouce the first alpa release of BackgrounDRb. This is a small framework for managing long running background tasks that allows for ajax progress bars and more. It also serves as an Application wide cache and context store for when you need something like sessions but shared between users and multiple backend processes like fcgi''s or mongrels.

Hi, Would greatly appreciate some help with this. Is the following error caused by an incorrect worker name? You have a nil object when you didn''t expect it! The error occurred while evaluating nil.send_request /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:44:in `ask_worker'' Here''s what I''m doing in my rails console.

I''ve been using backgroundrb since back in March 2007 or so. It''s been working mostly OK for me, but since the old version doesn''t seem to work out of the box with rails 2.0 for me, I decided to test out the latest version. So, I''m looking at the scheduling, and trying to figure out the best option for what I want to do. What I have is a set of workers that