search for: worker_method_arg

...for a single named worker instead, running as soon as possible. Using MiddleMan.schedule_worker() with :job_key does start off a worker, but I can''t manage to add another task to the same worker and have it queue up. It''s not just a matter of adding :worker_method => :do_work/:worker_method_args => whatever to schedule_worker()..? (see example below) Ideally using the same interface for running the first and any subsequent tasks. Here''s a debug run, which may or may not make any sense. Task a, b and c were started in 10-20 sec total, d was started after a and b finished...

Hi I have previously used railscron for server-side manipulation of the database but had a heap of trouble working with it. BackgrounDRB was suggested to me by a friend. I upload some files via acts_as_attachment and these go lie in a dir structure that i desire. What I want from the background process is to periodically (not user initiated) do some file-structure manipulation i.e. I want to

.... 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... :trigger_args: :start: <%= Time.now + 5.seconds %> :repeat_interval: <%= 1.minutes %> It''s currently launching two instances of city_updater, one minute apart fro the other. Hints or tips to avoid this ap...

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

...:end => Time.now + 10.minutes, :repeat_interval => 30.seconds } The cron trigger uses a similar syntax to cron found on UNIX systems: MiddleMan.schedule_worker( :class => simple_class, :job_key => :schedule_test, :worker_method => :arg_method, :worker_method_args => "my argument to arg_method", :trigger_args => "0 15 10 * * * *" ) Also note that when the server starts up, you will see 3 processes running. One of the is the MiddleMan server, one is the results worker and one is the logger worker. When you do a logger.in...

...} > > > > The cron trigger uses a similar syntax to cron found on UNIX systems: > > > > MiddleMan.schedule_worker( > > :class => simple_class, > > :job_key => :schedule_test, > > :worker_method => :arg_method, > > :worker_method_args => "my argument to arg_method", > > :trigger_args => "0 15 10 * * * *" > > ) > > > > > > Also note that when the server starts up, you will see 3 processes > > running. > > One of the is the MiddleMan server, one is the re...

Hi, I have backgroundrb running to decouple the execution of massive business logic from an ActionWebservice request. The service is designed to take some configuration parameters and fire a lot of background workers to do the requested work. Due to performance reasons I want to limit the number of workers to a maximum number of 30. But when I start a configuration that requires for example