similar to: Worker status bug in new version

Hi Folks, BackgrounDRb is a Ruby job server and scheduler. Its main intent is to be used with Ruby on Rails applications for offloading long-running tasks. Since a Rails application blocks while serving a request it is best to move long-running tasks off into a background process that is divorced from http request/response cycle. This new release of BackgrounDRb is also modular and can be used

Thank you. I got it working using the register_status . hemant kumar wrote: > On Fri, 2007-12-21 at 09:51 -1000, Kevin W. English wrote: > >> Hello, I recently upgraded to the new backgroundrb. I noticed that the >> "get_worker" method is gone. I am trying to create multiple instances of >> the same worker and retrieve the status of them using the job key:

Hello, First off, nice improvements hemant! Thanks for all the hard work. I just whipped up a new worker for a scheduled job that sends digest emails. Very smooth. However, moving some of my old backgroundrb into new backgroundrb isn''t going quite as smoothly. I have a import worker that takes a number of parameters and then is started dynamically. Here''s the a

Hi, I have a page were users can start jobs that may take several hours to run. BackgrounDrb is perfect for me and seems to be working well most of the time but some times I have the following problem: My worker is set up like this: class UploadWorker < BackgrounDRb::MetaWorker set_worker_name :upload_worker set_no_auto_load(true) def create(args = nil ) file = args[:file]

I''m trying to run a single worker that could perform a periodic task for a given user. >From a controller, I imagine something like: def start_job MiddleMan.ask_work(:worker => :foo_worker, :worker_method => :perform_task, :data => { :user_id = current_user.id }) end def check_job @status = MiddleMan.ask_status(:worker => :foo_worker)[current_user.id] end

Cc''ing to the list for archival purposes: On Tue, Mar 25, 2008 at 7:55 PM, Brian Noguchi <brian.noguchi at gmail.com> wrote: > Hi Hemant, > > I''m Brian Noguchi, a developer in the Bay Area. I have some questions about > backgroundrb, and I found your contact info on a forum. I figured its > probably best to get answers straight from the source. > >

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 new backgroundrb, asking status using job key

Hi, A pre-release version of backgroundrb is available now from svn. Download it from here: http://svn.devjavu.com/backgroundrb/branches/version099/ Since this release marks significant migration from existing practices, i intend to keep trunk untouched for a while. There are no install scripts, but you should copy "backgroundrb" file from script directory of plugin to script

Hello ! 1) I have this error logged by bdrb: undefined method `send_request'' for nil:NilClass framework/packet_master.rb:58:in `ask_worker'' backgroundrb/server/master_worker.rb:59:in `process_work'' backgroundrb/server/master_worker.rb:16:in `receive_data'' backgroundrb/framework/bin_parser.rb:29:in `call'' backgroundrb/framework/bin_parser.rb:29:in

Hi there, Amazing changes! I really like what you''ve done with BackgrounDRb and I hope you continue developing it, since it was definitely somewhat languishing before. One small error stuck out for me, though. The create method requires an argument even if one isn''t used, such that if you have: def create @results = Hash.new end The server throws an error about trying to

What does the method query_all_workers() do? There is no documentation on what this method returns (1.0.1 version). Orion -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080118/9f9b8112/attachment.html

Hi Folks, I am glad to announce 1.0 release of BackgrounDRb. This would be a major release since 0.2 release of BackgrounDRb. Here is a brief summary of changes: - BackgrounDRb is DRb no longer. It makes use of EventDriven network programming library packet ( http://packet.googlecode.com ). - Since we moved to packet, many nasty thread issues, result hash corruption issues are totally

This has been asked before, never well attended perhaps. Any thoughts on testing your workers? Current implementation is broken. An empty test case like this: require File.dirname(__FILE__) + ''/../test_helper'' require "#{RAILS_ROOT}/lib/workers/market_summary_worker" require "#{RAILS_ROOT}/vendor/plugins/backgroundrb/lib/backgroundrb.rb" require

Sorry if this comes through twice. I already sent this once, before joining the mailing list. I''m attempting to use Backgroundrb to handle asynchronous pdf creation, but in doing so, I''ve run into a very strange problem. Below is a method that''s called from the controller which creates a new worker, then grabs the worker and calls the ''build_pdf''

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

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

(Sorry my last email had the wrong subject) Hi, I''ve just installed background rb 0.2.1. When I try start a worker in my application controller I receive the following error: wrong number of arguments (2 for 1) - (ArgumentError) /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in `initialize''

Hi All, One can easily code a backgroundrb worker so as it can act as a worker queue, having reached a stable status, perhaps its time we should add this feature. Why? Because if you are already running your application using BackgrounDRb, perhaps you don''t want to manage other solutions when capability to do that is right there with you. Interface? This where i need feedback. You can

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

We have a fairly expensive task that we''d rather not schedule too many instances of in parallel. Couldn''t get pool_size to limit the amount of workers, and I figure that''s hardly optimal anyway, so would like to have the work queued up for a single named worker instead, running as soon as possible. Using MiddleMan.schedule_worker() with :job_key does start off a