From simon.wilkinson at 434wireless.com Wed Aug 1 09:34:09 2007 From: simon.wilkinson at 434wireless.com (simon.wilkinson at 434wireless.com) Date: Wed, 01 Aug 2007 09:34:09 -0400 Subject: [Backgroundrb-devel] stability of using scheduled workers Message-ID: <9602997.141131185975249056.JavaMail.servlet@perfora> Hi, Going through the archive, and just keeping a general watch on this list seems to indicate that there are some issues using scheduling with backgroundrb. I need a worker that will perform some actions on an hourly interval. These actions will require access to several of the models in my application. I am currently using backgroundrb to handle processing of files, where I spawn a worker to handle each file, and then destroy them afterwards. This is working great, and I would like to use backgroundrb for this scheduled action, but I need it to be reliable. What is the general feeling among those that are using it for this type of application? Does it reliably continue to fire at the proper intervals? Thanks, Simon From levent at leventali.com Thu Aug 2 04:16:02 2007 From: levent at leventali.com (Levent Ali) Date: Thu, 2 Aug 2007 09:16:02 +0100 Subject: [Backgroundrb-devel] stability of using scheduled workers In-Reply-To: <9602997.141131185975249056.JavaMail.servlet@perfora> References: <9602997.141131185975249056.JavaMail.servlet@perfora> Message-ID: <76685bc50708020116jccf78cbl8e06d255f01c76e6@mail.gmail.com> To be honest... My answer would be no... We have two scheduled workers that run hourly and are offset by thirty minutes... We cannot get the scheduler to go 24 hours without skipping a few schedules. That's if we are lucky. Usually it runs for at most a day and then never schedules again. I think it may have something to do with the scheduler code that sleeps for 0.1. There's a comment in the code near it. I'm thinking it may get into a rhythm where it misses the schedule point. We tried changing the schedule to prime numbers and other random points but the same thing eventually happened. What we do now instead is use standard linux cron and that calls a rake task that spawns a backgroundrb worker. Everything outside of the scheduler function works like a dream for us. Hope that helps.. Levent On 8/1/07, simon.wilkinson at 434wireless.com wrote: > Hi, > > Going through the archive, and just keeping a general watch on this list seems to indicate that there are some issues using scheduling with backgroundrb. I need a worker that will perform some actions on an hourly interval. These actions will require access to several of the models in my application. I am currently using backgroundrb to handle processing of files, where I spawn a worker to handle each file, and then destroy them afterwards. This is working great, and I would like to use backgroundrb for this scheduled action, but I need it to be reliable. > > What is the general feeling among those that are using it for this type of application? Does it reliably continue to fire at the proper intervals? > > Thanks, > > Simon > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > From benr at x-cr.com Fri Aug 3 12:29:18 2007 From: benr at x-cr.com (Ben Reubenstein) Date: Fri, 3 Aug 2007 10:29:18 -0600 Subject: [Backgroundrb-devel] stability of using scheduled workers In-Reply-To: <9602997.141131185975249056.JavaMail.servlet@perfora> References: <9602997.141131185975249056.JavaMail.servlet@perfora> Message-ID: <44c79a160708030929j75d98716qbe03fbdb8241a1fd@mail.gmail.com> Hello ~ I have found that a much better way to do scheduled tasks is to use script/runner with crontab or cron. You then get access to your entire rails environment very easily. So for example in crontab I have a task that runs every half-hour: 0,30 * * * * ruby /path/to/script/runner 'load "/path/to/your/script/my.rb"' I do however use backgroundrb for user initiated tasks such as processing a file and sending updates to the browser. I have found this to be extremely reliable. Hope this helps, Ben On 8/1/07, simon.wilkinson at 434wireless.com wrote: > Hi, > > Going through the archive, and just keeping a general watch on this list seems to indicate that there are some issues using scheduling with backgroundrb. I need a worker that will perform some actions on an hourly interval. These actions will require access to several of the models in my application. I am currently using backgroundrb to handle processing of files, where I spawn a worker to handle each file, and then destroy them afterwards. This is working great, and I would like to use backgroundrb for this scheduled action, but I need it to be reliable. > > What is the general feeling among those that are using it for this type of application? Does it reliably continue to fire at the proper intervals? > > Thanks, > > Simon > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Ben Reubenstein 303-947-0446 http://www.benr75.com From david.balatero at gmail.com Wed Aug 8 14:09:29 2007 From: david.balatero at gmail.com (David Balatero) Date: Wed, 8 Aug 2007 11:09:29 -0700 Subject: [Backgroundrb-devel] Server dying with perpetual "Connection reset by peer" In-Reply-To: <9833DF93-D73A-435A-952E-7647E9B03F6B@alumni.caltech.edu> References: <8bca3aa10707300806j749adef6t3304340d729d4a30@mail.gmail.com> <9833DF93-D73A-435A-952E-7647E9B03F6B@alumni.caltech.edu> Message-ID: <572c318d0708081109w503ea10dtfa9e8aef8448ea94@mail.gmail.com> I was able to solve this very problem by changing my host from "localhost" to "127.0.0.1" in my config/backgroundrb.yml file yesterday. Does that work for you? Some systems apparently have trouble resolving hostnames -- although localhost seems like a no-brainer to resolve... - David On 7/30/07, Daniel Azuma wrote: > > > On 30 Jul, 2007, at 08:06, Mason Hale wrote: > > > On 7/29/07, Daniel Azuma wrote: > >> This appears to be the same issue that Peer Allan observed back in > >> May-- in that case the workers were triggered on a schedule, but in > >> my case it is triggered via a remote MiddleMan. > > > > By "triggered via a remote MiddleMan" do you mean that one > > backgroundrb worker is spawning additional workers? If so, then > > that could be the problem. I had a lot of connection reset by peer > > errors when trying to spawn workers from other workers. > > Sorry, I didn't give a very clear description. All I meant was that > I'm not using the scheduler (which other people seem to be having > trouble with). I'm simply using MiddleMan from rails and spawning > workers that way, not trying to spawn workers from other workers. I > merely want to use backgroundrb to detach certain jobs from the HTTP > request and run them asynchronously. > > > If not, are you using Unix sockets? I've seen cases where the > > process names become very long, due to the class name and job key > > being concatenated into the process name. If the name is too long, > > then backgroundrb may not be able to locate a matching socket file > > to make the connection. If that might be the case, try shortening > > your class names and/or setting explicit, short jobkeys for your > > worker processes. > > I've tried both the drbunix and druby protocols, if that's what > you're asking, and have had the same result with both. (I assume the > difference between them is that the former uses unix sockets whereas > the latter uses ip?) However, I'll look into the process names > anyway. Thanks. > > Daniel > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070808/707e5a83/attachment.html From david.balatero at gmail.com Wed Aug 8 14:14:54 2007 From: david.balatero at gmail.com (David Balatero) Date: Wed, 8 Aug 2007 11:14:54 -0700 Subject: [Backgroundrb-devel] Cannot start workers in production mode Message-ID: <572c318d0708081114t6a09e57bu4a49633b768f88f5@mail.gmail.com> I have a job that I am starting from a Rails controller in production mode using MiddleMan: MiddleMan.new_worker(:class => :import_ccg_category_worker, :args => { :category_id => @category.id, :remote_category_id => params[:remote_category_id], :description => "Importing CCG products for #{@ category.name}" }) Both of the category ID variables are just basic integers. I have other places in my app that I use workers, and they are all producing the same error. I get the following on stderr when I run script/backgroundrb run: undefined method `wait' for nil:NilClass - (NoMethodError) /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:217:in `new_worker' /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch' /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `initialize' /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `new' /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `dispatch' /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in `new_worker' /usr/lib/ruby/1.8/drb/drb.rb:1555:in `__send__' /usr/lib/ruby/1.8/drb/drb.rb:1555:in `perform_without_block' /usr/lib/ruby/1.8/drb/drb.rb:1515:in `perform' /usr/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1585:in `loop' /usr/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1581:in `start' /usr/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1430:in `run' /usr/lib/ruby/1.8/drb/drb.rb:1427:in `start' /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' /usr/lib/ruby/1.8/drb/drb.rb:1347:in `initialize' /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' /usr/lib/ruby/1.8/drb/drb.rb:1627:in `start_service' /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:315:in `run' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:193:in `call' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:193:in `start_proc' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:203:in `call' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:203:in `start_proc' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:233:in `start' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/controller.rb:72:in `run' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons.rb:185:in `run_proc' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/cmdline.rb:105:in `call' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/cmdline.rb:105:in `catch_exceptions' /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons.rb:184:in `run_proc' /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in `run' script/backgroundrb:29 I am at a loss to explain what is going on here. BackgrounDRb::VERSION reports I run version 0.2.1 of backgroundrb. I have version 1.2.1 of slave, and version 1.0.6 of daemons installed. My backgroundrb.yml file is the following: --- port: "22222" timer_sleep: 60 load_rails: true environment: production host: 127.0.0.1 database_yml: config/database.yml acl: deny: all allow: localhost 127.0.0.1 order: deny,allow Hopefully someone can help me get through this, because I am in the middle of deploying our first app, and it would suck to be delayed any more. Thanks in advance! David Balatero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070808/9d8aee26/attachment.html From gethemant at gmail.com Wed Aug 8 16:49:23 2007 From: gethemant at gmail.com (hemant) Date: Thu, 9 Aug 2007 02:19:23 +0530 Subject: [Backgroundrb-devel] Cannot start workers in production mode In-Reply-To: <572c318d0708081114t6a09e57bu4a49633b768f88f5@mail.gmail.com> References: <572c318d0708081114t6a09e57bu4a49633b768f88f5@mail.gmail.com> Message-ID: On 8/8/07, David Balatero wrote: > I have a job that I am starting from a Rails controller in production mode > using MiddleMan: > > MiddleMan.new_worker(:class => :import_ccg_category_worker, :args => { > :category_id => @ category.id, :remote_category_id => > params[:remote_category_id], :description => "Importing CCG products for > #{@category.name}" }) > > Both of the category ID variables are just basic integers. I have other > places in my app that I use workers, and they are all producing the same > error. I get the following on stderr when I run script/backgroundrb run: > > undefined method `wait' for nil:NilClass - (NoMethodError) > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:217:in > `new_worker' > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in > `dispatch' > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > `initialize' > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > `new' > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > `dispatch' > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in > `new_worker' > /usr/lib/ruby/1.8/drb/drb.rb:1555:in `__send__' > /usr/lib/ruby/1.8/drb/drb.rb:1555:in > `perform_without_block' > /usr/lib/ruby/1.8/drb/drb.rb:1515:in `perform' > /usr/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop' > /usr/lib/ruby/1.8/drb/drb.rb:1585:in `loop' > /usr/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop' > /usr/lib/ruby/1.8/drb/drb.rb:1581:in `start' > /usr/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop' > /usr/lib/ruby/1.8/drb/drb.rb:1430:in `run' > /usr/lib/ruby/1.8/drb/drb.rb:1427:in `start' > /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' > /usr/lib/ruby/1.8/drb/drb.rb:1347:in `initialize' > /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' > /usr/lib/ruby/1.8/drb/drb.rb:1627:in `start_service' > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:315:in > `run' > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:193:in > `call' > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:193:in > `start_proc' > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:203:in > `call' > /usr/lib/ruby/gems/1.8/gems/daemons- > 1.0.6/lib/daemons/application.rb:203:in `start_proc' > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:233:in > `start' > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/controller.rb:72:in > `run' > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons.rb:185:in > `run_proc' > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/cmdline.rb:105:in > `call' > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/cmdline.rb:105:in > `catch_exceptions' > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons.rb:184:in > `run_proc' > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in > `run' > script/backgroundrb:29 > > I am at a loss to explain what is going on here. BackgrounDRb::VERSION > reports I run version 0.2.1 of backgroundrb. I have version 1.2.1 of slave, > and version 1.0.6 of daemons installed. My backgroundrb.yml file is the > following: > > --- > port: "22222" > timer_sleep: 60 > load_rails: true > environment: production > host: 127.0.0.1 > database_yml: config/database.yml > acl: > deny: all > allow: localhost 127.0.0.1 > order: deny,allow > > > Hopefully someone can help me get through this, because I am in the middle > of deploying our first app, and it would suck to be delayed any more. > > Thanks in advance! > David Balatero > Hey David, please update your plugin with trunk and make sure that you have slave 1.2.1. Also can you use this config file and see if you still get the error, i see couple of options that you are using aren't suppored at all: -- :host: 127.0.0.1 :port: 2999 :rails_env: production :worker_dir: lib/workers :acl: deny: all allow: localhost 127.0.0.1 order: deny,allow From gethemant at gmail.com Wed Aug 8 16:50:04 2007 From: gethemant at gmail.com (hemant) Date: Thu, 9 Aug 2007 02:20:04 +0530 Subject: [Backgroundrb-devel] Cannot start workers in production mode In-Reply-To: References: <572c318d0708081114t6a09e57bu4a49633b768f88f5@mail.gmail.com> Message-ID: On 8/9/07, hemant wrote: > On 8/8/07, David Balatero wrote: > > I have a job that I am starting from a Rails controller in production mode > > using MiddleMan: > > > > MiddleMan.new_worker(:class => :import_ccg_category_worker, :args => { > > :category_id => @ category.id, :remote_category_id => > > params[:remote_category_id], :description => "Importing CCG products for > > #{@category.name}" }) > > > > Both of the category ID variables are just basic integers. I have other > > places in my app that I use workers, and they are all producing the same > > error. I get the following on stderr when I run script/backgroundrb run: > > > > undefined method `wait' for nil:NilClass - (NoMethodError) > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:217:in > > `new_worker' > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in > > `dispatch' > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > > `initialize' > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > > `new' > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > > `dispatch' > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in > > `new_worker' > > /usr/lib/ruby/1.8/drb/drb.rb:1555:in `__send__' > > /usr/lib/ruby/1.8/drb/drb.rb:1555:in > > `perform_without_block' > > /usr/lib/ruby/1.8/drb/drb.rb:1515:in `perform' > > /usr/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop' > > /usr/lib/ruby/1.8/drb/drb.rb:1585:in `loop' > > /usr/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop' > > /usr/lib/ruby/1.8/drb/drb.rb:1581:in `start' > > /usr/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop' > > /usr/lib/ruby/1.8/drb/drb.rb:1430:in `run' > > /usr/lib/ruby/1.8/drb/drb.rb:1427:in `start' > > /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' > > /usr/lib/ruby/1.8/drb/drb.rb:1347:in `initialize' > > /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' > > /usr/lib/ruby/1.8/drb/drb.rb:1627:in `start_service' > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:315:in > > `run' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:193:in > > `call' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:193:in > > `start_proc' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:203:in > > `call' > > /usr/lib/ruby/gems/1.8/gems/daemons- > > 1.0.6/lib/daemons/application.rb:203:in `start_proc' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:233:in > > `start' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/controller.rb:72:in > > `run' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons.rb:185:in > > `run_proc' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/cmdline.rb:105:in > > `call' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/cmdline.rb:105:in > > `catch_exceptions' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons.rb:184:in > > `run_proc' > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in > > `run' > > script/backgroundrb:29 > > > > I am at a loss to explain what is going on here. BackgrounDRb::VERSION > > reports I run version 0.2.1 of backgroundrb. I have version 1.2.1 of slave, > > and version 1.0.6 of daemons installed. My backgroundrb.yml file is the > > following: > > > > --- > > port: "22222" > > timer_sleep: 60 > > load_rails: true > > environment: production > > host: 127.0.0.1 > > database_yml: config/database.yml > > acl: > > deny: all > > allow: localhost 127.0.0.1 > > order: deny,allow > > > > > > Hopefully someone can help me get through this, because I am in the middle > > of deploying our first app, and it would suck to be delayed any more. > > > > Thanks in advance! > > David Balatero > > > > Hey David, > > please update your plugin with trunk and make sure that you have slave 1.2.1. > > Also can you use this config file and see if you still get the error, > i see couple of options that you are using aren't suppored at all: > :host: 127.0.0.1 :port: 2999 :rails_env: production :worker_dir: lib/workers :acl: deny: all allow: localhost 127.0.0.1 order: deny,allow -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://blog.gnufied.org From david.balatero at gmail.com Thu Aug 9 15:27:55 2007 From: david.balatero at gmail.com (David Balatero) Date: Thu, 9 Aug 2007 12:27:55 -0700 Subject: [Backgroundrb-devel] Cannot start workers in production mode In-Reply-To: References: <572c318d0708081114t6a09e57bu4a49633b768f88f5@mail.gmail.com> Message-ID: <572c318d0708091227k5505eb49rec9bca89d7e23be4@mail.gmail.com> I'm having a hell of a time with this. I tried checking out a new version from trunk, as well as modifying my backgroundrb.yml to what you suggested. Next, I'm going to try running it on a different server and see if that fixes this. - David On 8/8/07, hemant wrote: > > On 8/8/07, David Balatero wrote: > > I have a job that I am starting from a Rails controller in production > mode > > using MiddleMan: > > > > MiddleMan.new_worker(:class => :import_ccg_category_worker, :args => { > > :category_id => @ category.id, :remote_category_id => > > params[:remote_category_id], :description => "Importing CCG products for > > #{@category.name}" }) > > > > Both of the category ID variables are just basic integers. I have other > > places in my app that I use workers, and they are all producing the same > > error. I get the following on stderr when I run script/backgroundrb run: > > > > undefined method `wait' for nil:NilClass - (NoMethodError) > > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:217:in > > `new_worker' > > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in > > `dispatch' > > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > > `initialize' > > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > > `new' > > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > > `dispatch' > > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in > > `new_worker' > > /usr/lib/ruby/1.8/drb/drb.rb:1555:in `__send__' > > /usr/lib/ruby/1.8/drb/drb.rb:1555:in > > `perform_without_block' > > /usr/lib/ruby/1.8/drb/drb.rb:1515:in `perform' > > /usr/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop' > > /usr/lib/ruby/1.8/drb/drb.rb:1585:in `loop' > > /usr/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop' > > /usr/lib/ruby/1.8/drb/drb.rb:1581:in `start' > > /usr/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop' > > /usr/lib/ruby/1.8/drb/drb.rb:1430:in `run' > > /usr/lib/ruby/1.8/drb/drb.rb:1427:in `start' > > /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' > > /usr/lib/ruby/1.8/drb/drb.rb:1347:in `initialize' > > /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' > > /usr/lib/ruby/1.8/drb/drb.rb:1627:in `start_service' > > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:315:in > > `run' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6 > /lib/daemons/application.rb:193:in > > `call' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6 > /lib/daemons/application.rb:193:in > > `start_proc' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6 > /lib/daemons/application.rb:203:in > > `call' > > /usr/lib/ruby/gems/1.8/gems/daemons- > > 1.0.6/lib/daemons/application.rb:203:in `start_proc' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6 > /lib/daemons/application.rb:233:in > > `start' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6 > /lib/daemons/controller.rb:72:in > > `run' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons.rb:185:in > > `run_proc' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/cmdline.rb:105:in > > `call' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/cmdline.rb:105:in > > `catch_exceptions' > > /usr/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons.rb:184:in > > `run_proc' > > > /mnt/home/magicarsenal/admin/releases/20070807014939/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in > > `run' > > script/backgroundrb:29 > > > > I am at a loss to explain what is going on here. BackgrounDRb::VERSION > > reports I run version 0.2.1 of backgroundrb. I have version 1.2.1 of > slave, > > and version 1.0.6 of daemons installed. My backgroundrb.yml file is the > > following: > > > > --- > > port: "22222" > > timer_sleep: 60 > > load_rails: true > > environment: production > > host: 127.0.0.1 > > database_yml: config/database.yml > > acl: > > deny: all > > allow: localhost 127.0.0.1 > > order: deny,allow > > > > > > Hopefully someone can help me get through this, because I am in the > middle > > of deploying our first app, and it would suck to be delayed any more. > > > > Thanks in advance! > > David Balatero > > > > Hey David, > > please update your plugin with trunk and make sure that you have slave > 1.2.1. > > Also can you use this config file and see if you still get the error, > i see couple of options that you are using aren't suppored at all: > > -- > :host: 127.0.0.1 > :port: 2999 > :rails_env: production > :worker_dir: lib/workers > :acl: > deny: all > allow: localhost 127.0.0.1 > order: deny,allow > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070809/a78f1d3f/attachment.html From eimorton at gmail.com Thu Aug 16 12:02:33 2007 From: eimorton at gmail.com (Erik Morton) Date: Thu, 16 Aug 2007 12:02:33 -0400 Subject: [Backgroundrb-devel] Redirect STDOUT? Message-ID: If I'm not mistaken, BackgroundRB itself redirect STDOUT. Daemons redirects STDOUT to dev/null. What are your thoughts on re-re- directing STDOUT? I'd like to use an existing library within BackgroundRB that has extensive use of puts, and I'm not sure of the best way to get that output back in a useful place. Your thoughts are appreciated. Erik From simon.wilkinson at 434wireless.com Thu Aug 16 12:32:10 2007 From: simon.wilkinson at 434wireless.com (Simon) Date: Thu, 16 Aug 2007 12:32:10 -0400 Subject: [Backgroundrb-devel] stability of using scheduled workers In-Reply-To: <44c79a160708030929j75d98716qbe03fbdb8241a1fd@mail.gmail.com> References: <9602997.141131185975249056.JavaMail.servlet@perfora> <44c79a160708030929j75d98716qbe03fbdb8241a1fd@mail.gmail.com> Message-ID: <000901c7e023$0235b5a0$0b01a8c0@DCDGLG81> Hi, I have tried this, and can't seem to get it going. Is there anything special that needs to be done to the script? I also tried to just set up a test through one of the models, where it would just print the current time to a file, just to see if that would work. It also didn't work. Here is the line I had in my crontab: * * * * * ruby /var/www/rails/434Wireless/script/runner "Ping.test_cron" And here is the function in my Ping model: def self.test_cron test = Time.now.to_s(:db) system("echo #{test} >> /var/log/test.log") end So I just want the current time added to a file, and for it to trigger every minute (useless I know, but I'm just testing things here :) ). When I just run 'ruby /var/www/rails/434Wireless/script/runner "Ping.test_cron"' from the command line, everything works perfectly. Any ideas on what is happening? Thanks, Simon -----Original Message----- From: benr75 at gmail.com [mailto:benr75 at gmail.com] On Behalf Of Ben Reubenstein Sent: 03 August 2007 12:29 To: simon.wilkinson at 434wireless.com Cc: backgroundrb-devel at rubyforge.org Subject: Re: [Backgroundrb-devel] stability of using scheduled workers Hello ~ I have found that a much better way to do scheduled tasks is to use script/runner with crontab or cron. You then get access to your entire rails environment very easily. So for example in crontab I have a task that runs every half-hour: 0,30 * * * * ruby /path/to/script/runner 'load "/path/to/your/script/my.rb"' I do however use backgroundrb for user initiated tasks such as processing a file and sending updates to the browser. I have found this to be extremely reliable. Hope this helps, Ben On 8/1/07, simon.wilkinson at 434wireless.com wrote: > Hi, > > Going through the archive, and just keeping a general watch on this list seems to indicate that there are some issues using scheduling with backgroundrb. I need a worker that will perform some actions on an hourly interval. These actions will require access to several of the models in my application. I am currently using backgroundrb to handle processing of files, where I spawn a worker to handle each file, and then destroy them afterwards. This is working great, and I would like to use backgroundrb for this scheduled action, but I need it to be reliable. > > What is the general feeling among those that are using it for this type of application? Does it reliably continue to fire at the proper intervals? > > Thanks, > > Simon > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Ben Reubenstein 303-947-0446 http://www.benr75.com From me at seebq.com Thu Aug 16 13:03:43 2007 From: me at seebq.com (Charles Brian Quinn) Date: Thu, 16 Aug 2007 13:03:43 -0400 Subject: [Backgroundrb-devel] stability of using scheduled workers In-Reply-To: <000901c7e023$0235b5a0$0b01a8c0@DCDGLG81> References: <9602997.141131185975249056.JavaMail.servlet@perfora> <44c79a160708030929j75d98716qbe03fbdb8241a1fd@mail.gmail.com> <000901c7e023$0235b5a0$0b01a8c0@DCDGLG81> Message-ID: <3a2de0cd0708161003y3fa2888du143bddfd0a2bd04a@mail.gmail.com> Use the full path to ruby: /usr/local/bin/ruby /var/www/rails/434Wireless/script/runner "Ping.test_cron" On 8/16/07, Simon wrote: > Hi, > > I have tried this, and can't seem to get it going. Is there anything > special that needs to be done to the script? > > I also tried to just set up a test through one of the models, where it would > just print the current time to a file, just to see if that would work. It > also didn't work. > > Here is the line I had in my crontab: > * * * * * ruby /var/www/rails/434Wireless/script/runner "Ping.test_cron" > > And here is the function in my Ping model: > def self.test_cron > test = Time.now.to_s(:db) > system("echo #{test} >> /var/log/test.log") > end > > So I just want the current time added to a file, and for it to trigger every > minute (useless I know, but I'm just testing things here :) ). When I just > run 'ruby /var/www/rails/434Wireless/script/runner "Ping.test_cron"' from > the command line, everything works perfectly. Any ideas on what is > happening? > > Thanks, > > Simon > > -----Original Message----- > From: benr75 at gmail.com [mailto:benr75 at gmail.com] On Behalf Of Ben > Reubenstein > Sent: 03 August 2007 12:29 > To: simon.wilkinson at 434wireless.com > Cc: backgroundrb-devel at rubyforge.org > Subject: Re: [Backgroundrb-devel] stability of using scheduled workers > > Hello ~ > > I have found that a much better way to do scheduled tasks is to use > script/runner with crontab or cron. You then get access to your > entire rails environment very easily. So for example in crontab I > have a task that runs every half-hour: > > 0,30 * * * * ruby /path/to/script/runner 'load "/path/to/your/script/my.rb"' > > I do however use backgroundrb for user initiated tasks such as > processing a file and sending updates to the browser. I have found > this to be extremely reliable. > > Hope this helps, > > Ben > > On 8/1/07, simon.wilkinson at 434wireless.com > wrote: > > Hi, > > > > Going through the archive, and just keeping a general watch on this list > seems to indicate that there are some issues using scheduling with > backgroundrb. I need a worker that will perform some actions on an hourly > interval. These actions will require access to several of the models in my > application. I am currently using backgroundrb to handle processing of > files, where I spawn a worker to handle each file, and then destroy them > afterwards. This is working great, and I would like to use backgroundrb for > this scheduled action, but I need it to be reliable. > > > > What is the general feeling among those that are using it for this type of > application? Does it reliably continue to fire at the proper intervals? > > > > Thanks, > > > > Simon > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > -- > Ben Reubenstein > 303-947-0446 > http://www.benr75.com > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot rails business hosting: www.slingshothosting.com main: 404.394.4935 fax: 678.826.0969 Ruby on Rails Bootcamp at the Big Nerd Ranch Intensive Ruby on Rails Training: http://www.bignerdranch.com/classes/ruby.shtml From yem_backgroundrb-devel at filter.yve.net Wed Aug 22 22:48:10 2007 From: yem_backgroundrb-devel at filter.yve.net (Yves-Eric Martin) Date: Thu, 23 Aug 2007 11:48:10 +0900 Subject: [Backgroundrb-devel] "interning empty string - (ArgumentError)" passing AR objects between workers Message-ID: <46CCF56A.6020909@filter.yve.net> Hi all, I need some help with this setup I am trying to get working with BackgrounDRb: An autostarted "dispatcher" worker runs every minute and polls some table for jobs that need to be run at that time. For each job found, the "dispatcher" spawns a "runner" worker that runs the job. So in my "dispatcher" worker, I have some code like this: MiddleMan.new_worker(:class => :runner_worker, :args => job) I did add "include DRbUndumped" in my Job model, and it works fine directly from the console. But from the "dispatcher" worker, I get the following error (see full traceback attached): "interning empty string - (ArgumentError)" How can I get this to work? Is this a known bug? Or is what I am trying to do (spawning workers from a worker) not supported? Thanks for your help. PS: Looks like my 1st message didn't make it through. Sorry if this becomes a double-post. -- Yves-Eric Martin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dispatcher_traceback.txt Url: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070823/c75017bf/attachment.txt