search for: job_key

...elected servers in a session session[:selectedservers] = params[:servers] session[:running_cmd] = 1 @selected_servers = System.find_all_by_id(params[:servers]) @selected_servers.each do |svr| # spawn new process MiddleMan.new_worker(:worker => :remote_command_worker, :job_key => svr.name) MiddleMan.ask_work(:worker => :remote_command_worker, :job_key => svr.name, :worker_method => :do_work, :data => {:svr => svr.name, :command => MultiComCommand.find_by_id(params[:commando]).command}) end end When I select only a few servers, it works j...

Hi, Is it possible to start a worker with job_key and then ask_status of that specific worker with the job_key? MiddleMan.ask_work(:worker => :auth_worker, :job_key=>''1'', :worker_method => :auth) and then MiddleMan.ask_status(:worker => :auth_worker, :job_key=>''1'') >From my testing of the n...

Hello all, I''ve come up w/ a worker class that manages queued jobs using a fixed number of child workers. Well, that''s not quite true -- a new worker is spawned for each job, but you set the total number that may exist at once. There are three components: 1) queue_worker.rb: The singleton worker that manages the child workers. You probably want to auto start this. Make sure you

...e to get it right. In MiddleMan::new_worker(), the job is first created, then started. This is because the instance functions I added to BackgrounDrb::Rails don''t seem to be available when kicked off from BackgrounDRb::Rails.initialize() def new_worker(opts={}) @mutex.synchronize { job_key = opts[:job_key] || gen_key unless self[job_key] self[job_key] = instantiate_worker(opts[:class]).new(job_key,opts[:args]) self[job_key].start_process return job_key else raise ::BackgrounDRbDuplicateKeyError end } end In MiddleMan::delete_worker(), I''...

Hi, pardon if this is a duplicate mail, I forgot to click the subscription link the first time around. I''ve been using backgroundrb for a while now (older version) and I''ve had so many headaches because of it that I began looking for a replacement technology. And then I saw the new and shiny backgroundrb website, looking good! Initially I used the version maintained by

...ng at the current version. I''m guessing that it''s probably not OK for me to use create() the way I was using do_work() in the past; Presumably create() is supposed to return at some point. Besides which, one of my workers needs to have multiple instances, so I have to pass in a job_key somewhere. I''m guessing that I should call MiddleMan.new_worker(), telling it to run my main_work() method with some scheduling option, but I''m not sure which scheduling option to use. I don''t want to schedule it to run every 10 seconds, since each call to main_work cou...

...@logger.debug e.inspect if e[1].class.name == klasse return e[0] end end return nil end def new_singleton_worker(opts={}) @mutex.synchronize { worker = get_worker_by_class(opts[:class]) if worker.nil? job_key = opts[:job_key] || gen_key unless self[job_key] self[job_key] = instantiate_worker(opts[:class]).new(opts [:args]) return job_key else raise "job_key: #{job_key} already refers to a running worker" end el...

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

...(args) > while @progress < 100 > @progress += 1 > end > end > > end > > [ operations_controller.rb ] > > class OperationsController < ApplicationController > sidebar :general > sidebar :operations > > # start new worker and put the job_key into the session so you can > # get the status of your job later. > def background_task > session[:job_key] = MiddleMan.new_worker(:class => :ping_worker, > :args => {:baz => > ''hello!'', :qux => ''an...

Hi all I''m experiencing something strange with a :job_key, it took me a very long time to find out a worker wasn''t doing it''s job because of the name of my job_key. The first one I tried was :make_kohier, and with that name (and lot''s of other ones) I can''t get the worker to work. I do get my key in return, but...

Quick question: If I want to schedule different worker methods defined in the same worker to trigger at different times, is this possible? Would the following scheduler yaml work? :schedules: :foo_worker: :worker_method: method1 :trigger_args: 0 */10 * * * * * :job_key: some_key_1 :foo_worker: :worker_method: method2 :trigger_args: 0 */15 * * * * * :job_key: some_key_2 Would this work? Is there some other way to do it? Would the second method need to be pulled into a separate worker? Thanks, Andy -------------- next part -------------- An HTML...

...me thing is by calling ask_work with a bogus worker name. Calling it with the production code causes no error. Here''s an example of what the code calls: MiddleMan.ask_work(:worker => :agronomy_worker, :worker_method => :transmit, :data => 414) I also tried playing with adding a job_key, but that didn''t seem to change anything. Should I be providing a job_key and ensuring that it''s unique? I''ve no need to reference the job in progress, so I''m fine with the default key, unless of course it''s likely to be non-unique and cause a bug. Anyo...

...----- controller app/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...

Hi there, Backgroundrb is working pretty well for me but I have a job that launches two of the same job, apparently a minute(?) apart from each other. Should this be happening if I have repeat interval enabled with a job_key? It seems like it should wait until the job is finished before launching a new instance. --Backgroundrb_schedules.yml-- city_updater: :class: :city_updater_worker :job_key: :city_updater :worker_method: :do_work :worker_method_args: scheduled workers require some args, so here you go......

...9;t work. I''m not sure where else I should include it. I know that eventually I''ll need to put it in the non-test class that calls new_worker, but I''m not there yet. Is testing workers just a non-starter? Here''s the test method: def test_task_is_triggered job_key = MiddleMan.new_worker :class => :task_checker_worker, :args => tasks(:should_be_triggered) @job_keys << job_key # ...assertions go here... end thanks, jh -- James Hughes Web application developer Vancouver, BC "Developing a coherent political analysis is...

I am sure..again I am missing something, but I am trying to start a worker, when backgroundrb starts and it doesn''t seem to work. Here is my config/backgroundrb_schedules.yml file: feed_worker: class: feed_worker job_key: feed_worker_key worker_method: do_work trigger_args: repeat_interval: 20.minutes I even tried this from Rails controller: # def start_feed_worker # begin # MiddleMan.schedule_worker(:class => :feed_worker, # :args => "foobar",...

...9;'s '' * 512 end end class LargeWorker < BackgrounDRb::MetaWorker set_worker_name :large_worker set_no_auto_load(true) attr_reader :payload def create(args) @payload = ''L'' * 65600 end end I''ll start with SmallWorker. Created by: @job_key = rand 1000 # Nevermind the weak job keys for now. MiddleMan.new_worker(:worker => :small_worker, :data => ''not used'', :job_key => @job_key) then retrieved with: @ret = MiddleMan.send_request(:worker => :small_worker, :job_key => @job_key,...

...orker 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 < BackgrounDRb::MetaWorker set_worker_name :update...

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 duplicated. The code inside the worker is somethi...

I thought I could delete a busy worker by calling MiddleMan.delete_worker, but doesn''t seem to end. I believe this was possible in 0.2, is it not in 1.0? thanks, Zach -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080103/0c701f29/attachment.html