search for: jobkey

...exit end end Now when I fire up the backroundrb server and a rails console and ask for a new worker like this: >> jk = MiddleMan.new_worker(:worker => :upload_worker, :job_key => "123", :data => data) (where data = {:file => some_file} ) most of the time I get the jobkey returned and the job works and I can ask the status with >> MiddleMan.ask_status(:worker => :upload_worker, :job_key => "123") But sometimes I get the jobkey returned from the initial request but the worker seems to fail to register its status. In some cases the job is actual...

...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 method main_work sleep @sleep_time end end That seemed to work pretty well for the most part. So now, looking at the current version. I''m guessing that it''s probably not OK for me to use crea...

...ter issuing "eval "ObjectSpace.each_object(Slave){|x| p x if !x.status}"" I''ve got a strange result though: #<Slave:0x34c0fb0 @shutdown=false, @obj=#<BackgrounDRb::Worker::WorkerResults:0x34c0fc4 @worker_results={}, @initial_do_work=true, @results={}, @args=nil, @jobkey=:backgroundrb_results>, @lifeline=#<Slave::LifeLine:0x34c0858 @pair=[#<Socket:0x34c07e0>, nil], @fds=[9, 10], @pid=27245, @socket=#<Socket:0x34c07e0>, @object_id=27657260, @owner=27245>, @socket_creation_attempts=42, @dumped=nil, @pid=27248, @status=nil, @debug=false, @object=#...

...rge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > Hey Sherwin- > > This could be coded up to work for you. You would basically write a class that wraps multiple middleman clients and tries to get the workers by checking for MiddleMan.jobs.keys.include? session [:jobkey] . So you could have MiddleMan1, MiddleMan2..MiddleManN . >And just make a wrapper that iterates over each midleman checking to see if it contains the job you are looking for and using the right middleman. > This would not be too hard to come up with and I might add something to support this...

I''m at a loss to explain a very strange error I''m getting. This seems to happen on our production system where we have a backgroundrb server sharing a host with a Rails app running on Mongrel. The first one or two, occasionally three, calls to a worker (direct MiddleMan calls from Rails, not scheduled) succeed, but afterwards, the server fails to initialize new workers.

Howdy Folks- I''m happy to announce a new release of BackgrounDRb! I have added quite a few new features and included some nice patches from folks on the list. $ script/plugin install svn://rubyforge.org//var/svn/backgroundrb All of the code now stays within the plugin and the start and stop scripts are now just stubs. This makes it easier to tweak or figure out how it works.

i''m in a team that is currently developing a web 2.0 application that really needs to scale in the very near future. we are using backgroundrb for some of the server tasks. currently, we have two servers (in RubyOnRails) that connects to a single backgroundrb daemon. is there a way that we can run multiple backgroundrb and have the servers do a round robin on them to retrieve a worker

Hi, I''m having a problem where connections started through BackgrounDRb::MiddleManDRbObject.init are not stopped, resulting in an ever growing established connections between my Mongrels and remote backgroundrbs I added DRb.stop_service to my code executed after requests that init MiddleManDRbObjects but that does not help. Any ideas? Thanks, Robert Bjarnason

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

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