search for: new_work

I have a test case where I''m stubbing one method (''jobs''), and mocking another (''new_worker'') MiddleMan.stubs(:jobs) MiddleMan.expects(:new_worker).with{|args| args[:class] ==:download_worker} MiddleMan.jobs() The above code results in an error ("The error occurred while evaluating nil.[]") - calling ''jobs'' results in the with-arguments block...

...) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in `new'' 20070130-12:03:03 (92473) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in `new_worker'' 20070130-12:03:03 (92473) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch'' 20070130-12:03:03 (92473) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/se...

I''ve been checking out all the async gems and plugins for Rails, and decided to give BackgroundRb a shot. Unfortunately, I''ve not even been able to get past the initial stages. Whenever I call MiddleMan.new_worker, it invariably returns nil. The log file remains empty. I''ve only tried this from the console so far. If I can''t even do this successfully, I''m in no mood to try to start to write code, I''ve followed the example instructions to the letter, and confirmed that...

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

I''ve now got 5 processes auto started. But I when I query the MiddleMan for their keys (in script/console), it doesn''t find them. Looking at the start script, it looks like it might be creating a new MiddleMan object for each autostart BackgrounDRb::MiddleMan.new.new_worker(:class => entry[''class''], Even changing it to BackgrounDRb::MiddleMan.new_worker(:class => entry[''class''], didn''t seem to take care of it. I even tried to create a single MiddleMan and pass that to autostart, still to no avail. Is there...

...sage "some read error" and then the worker refuses to run again. I''ve stripped my worker down to just doing a puts and it still happens. Like the other threads I want to launch my workers as needed, however I get the same behavior whether use the auto_load and ask_work or use new_worker with no_auto_load. If I remove the job_key I can get it to work, but I still get the "Some read error" message. I need the job to keep one worker per id. I''d rather have separate processes than go the thread route - for now. class UpdateFacebookAccountInfoWorker < Backg...

Hi there, I''m trying to create a worker to do some asynchronous web client work and update the data model with its results. It seems, however, that every call I make to an ActiveRecord subclass causes the whole thing to block. At least I think it''s blocked. Right now I''m just using debug log output. Is there a decent way to debug/test workers I can try? Is there any

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 after five seconds, it''s not duplica...

Hello there, I need a Worker Class to be Singleton-like, that means there must be at maximum one Instance at a time. When a new Request is made to create another worker of this type, it should return and wait for the other instance to be destroyed. what i need to do: i have a worker who needs to do sth with java and openoffice, and it seems when i have more tha one worker simultaneously,

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"})...

...however long that may take), then pause for a "sleep time" and start over. With the old version of backgroundrb, I was never able to get any of the scheduling options to quite do what I wanted to do, so I just ran without scheduling. I manually started all my workers by calling MiddleMan.new_worker in a script, passing in the "sleep time", and then implemented each worker something like this: def do_work(args) @args = args @sleep_time = @args[:sleep_time] logger.info "CampaignStarter #{jobkey} started" while(true) # do the actual work in another...

...passwd/index -------------------- class Passwd::IndexController < ApplicationController layout ''default'' def index $subtitle = "AIX user inventory tool" end def createReport Passwdentry.delete_all User.delete_all session[:job_key] = MiddleMan.new_worker(:class => "passwd:get_passwds_worker", :args => "") end def get_progress if request.xhr? progress_percent = MiddleMan.get_worker(session[:job_key]).progress render :update do |page| page.call(''progressPercent'', ''pro...

Since MiddleMan is an uninitialized constant in a worker how do you create new workers inside a worker? Thank You, Ben Johnson E: bjohnson at contuitive.com O: 800-341-6826 M: 817-229-4258 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060731/75a77fa6/attachment-0001.html

...traints(report,start_time,false) args = { :constraints => constraints, :start_time => start_time, :report_params => report } # For reasons unknown, the following seems to block! session[:xml_report_job] = MiddleMan.new_worker(:class => :xml_report_worker, :args => args) end def get_progress ... worker = MiddleMan.worker(session[job]) end ... end class XmlReportWorker < BackgrounDRb::Worker::RailsBase include DRbUndumped ... def do_work(args) @progress = 0 @re...

Here''s something strange! the_job_key = MiddleMan.new_worker( :class => :log_view_to_sf_worker, :args => "just a string" ) works fine. But the_job_key = MiddleMan.new_worker( :class => :log_view_to_sf_worker, :args => { :landing_page => @landing_page, :driver => @driver } ) does not. It is as if :arg...

If I add .instance in front of new_worker I get the following error ... but for some reason i cant call new_worker directly...? error: ruby sample_app.rb my sample app :) ./backgroundrb/middleman.rb:440:in `ex'': undefined method `synchronize'' for nil:NilClass (NoMethodError) from ./backgroundrb/middleman.rb:401...

Hello, Trying to get the example to work in standalone mode. I have the following in a file and am not certain why I get this undefined method error: error: ~/ruby sample_app.rb my sample app :) sample_app.rb:9: undefined method `new_worker'' for BackgrounDRb::MiddleMan:Class (NoMethodError) ### code follows ### # sample_app ... try to get stand-alone happiness. #require ''release-0.2.1/lib/backgroundrb'' #MiddleManDRbObject.init(:uri =>''drbunix:///tmp/backgroundrbunix_localhost_2000'')...

Hey all, Been reading through all the old posts (and the docs) to familiarize myself but I still feel a bit lost. I''m on trunk and am having a bit of a hard time knowing where to start with the particular I''m trying to solve. So far, I''ve downloaded backgroundrb, done the basic rails setup, created my worker and started it using `script/backgroundrb start`.

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 that these will be started by a script in /etc/rc?.d. It seems like using the backgroundrb scheduler is not a possibility,...

...:ttl param defaults to 30 minutes for worker classes and 10 minutes for cached objects. If you don;t specify the :ttl param then thats how long your stuff will last. If you want longer or shorter ttl''s then specify :ttl in *seconds* like this: #worker session[:job_key] = MiddleMan.new_worker(:class => :foo_worker, :args => "Bar", :ttl => 300) # 300 seconds == 5 minutes #caching #fill_cache, expir...