From matthibcn at gmail.com Thu Feb 1 13:50:08 2007 From: matthibcn at gmail.com (matthibcn) Date: Thu, 01 Feb 2007 19:50:08 +0100 Subject: [Backgroundrb-devel] file_column 2nd try.... Message-ID: <45C23660.1080602@gmail.com> Looks like my first question a couple of days ago wasn?t very clever asked, at least very sucessfull.... So, anyway...i will try it again: I have to prefix that I am far away from fully understanding the overall concept yet, and there?s no way to get some hints in the www so far, at least my resaerches dont lead to any helpfull stuff. image_controller.rb: def create MiddleMan.new_worker :class => :image_worker, :job_key => :upload_img, :args => { :image => params[:image]} worker = ::MiddleMan.worker(:upload_img) end image_worker.rb require 'RMagick' class ImageWorker < BackgrounDRb::Worker::RailsBase ##attr_accessor :text def do_work(args) ##@text = args[:text] @image = Image.new(args[:image]) @image.dimensions @image.save end def progress results[:progress] end end ImageWorker.register image.rb require 'RMagick' class Image < ActiveRecord::Base belongs_to :user validates_filesize_of :image, :in => 15.kilobytes..1.megabyte validates_file_format_of :image, :in => ["gif", "png", "jpg"] file_column :image, :magick => {:versions => {"thumb" => "150x100", "picture" => "600x450>"}} def dimensions img = Magick::Image.read(self.image).first if img.columns >= img.rows ratio = img.columns.to_f / 600 else ratio = img.rows.to_f / 450 end self.width = ((img.columns / ratio)+10).to_i self.height = ((img.rows / ratio)+10).to_i end end So, this isn?t working...in fact I would be surprised if it would be that easy, as I just shifet code away from the controller to the worker... Ok: when submitting the uploadform at least the worker get fired and passed the args as expected, as I can see in the backgroundrb_server.log: 20070201-10:47:29 (53830) Starting worker: image_worker upload_img (image_worker_upload_img) (imagecreated_on(2i)2created_on(3i)1created_on(4i)00created_on(5i)18updated_on(1i)2007updated_on(2i)2image_tempdescriptionbackgrounDRb33updated_on(3i)1imgnum007updated_on(4i)00image#updated_on(5i)18created_on(1i)2007) Now there are 2 questions: the image isnt uploaded, that is probably due to the fact that the file_columnPlugin isnt available for the backgrounDRbserver.. My research turned out, that for the earlier version of the backgrounDRb you had to insert //require File.dirname(__FILE__) + "/../../config/environment.rb" // in the scrip/backgroundrb/start script..there is no such script in the actuall version and i cant see where to put that now. So, anyway, also if the image isnt uploaded physically shouldnt i expect at least an DB entry for the passed args as I call the save method on @image ?? Further I think the dimension method should go also in the worker, but step by step, and I am still totaly lost, so I just ask you kindly again to provide some input to enlighten me and others, as I guess that a lot of ppl are still missing some real world examples except of some cronlike or outdated stuff best regards matthias From ezmobius at gmail.com Thu Feb 1 15:18:02 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Thu, 1 Feb 2007 12:18:02 -0800 Subject: [Backgroundrb-devel] file_column 2nd try.... In-Reply-To: <45C23660.1080602@gmail.com> References: <45C23660.1080602@gmail.com> Message-ID: Hey there- I think you have a misconception of what backgroundrb can be used for. There is no way to use backgroundrb to do a progress bar for a file upload. Because the entire image will have to be uploaded before rails will pass it to backgroundrb. Looking at your code I think you are better off not using backgroundrb and just doing what you are doing all in rails. Is that your goal? TO have a progress bar for file uploads? If so you are barking up the wrong tree sorry. You can look at the mongrel_upload_progress gem to see about progress bars for file uploads. Cheers- -Ezra On Feb 1, 2007, at 10:50 AM, matthibcn wrote: > Looks like my first question a couple of days ago wasn?t very clever > asked, at least very sucessfull.... > > So, anyway...i will try it again: > > I have to prefix that I am far away from fully understanding the > overall > concept yet, and there?s no way to get some hints in the www so > far, at > least my resaerches dont lead to any helpfull stuff. > > image_controller.rb: > > def create > MiddleMan.new_worker :class => :image_worker, > :job_key => :upload_img, > :args => { :image => params[:image]} > worker = ::MiddleMan.worker(:upload_img) > end > > image_worker.rb > > require 'RMagick' > > class ImageWorker < BackgrounDRb::Worker::RailsBase > > ##attr_accessor :text > > def do_work(args) > ##@text = args[:text] > @image = Image.new(args[:image]) > @image.dimensions > @image.save > end > > def progress > results[:progress] > end > end > ImageWorker.register > > image.rb > > require 'RMagick' > > class Image < ActiveRecord::Base > belongs_to :user > > validates_filesize_of :image, :in => 15.kilobytes..1.megabyte > validates_file_format_of :image, :in => ["gif", "png", "jpg"] > > file_column :image, :magick => {:versions => {"thumb" => "150x100", > "picture" => "600x450>"}} > > def dimensions > img = Magick::Image.read(self.image).first > if img.columns >= img.rows > ratio = img.columns.to_f / 600 > else > ratio = img.rows.to_f / 450 > end > self.width = ((img.columns / ratio)+10).to_i > self.height = ((img.rows / ratio)+10).to_i > end > > end > > So, this isn?t working...in fact I would be surprised if it would be > that easy, as I just shifet code away from the controller to the > worker... > > Ok: > > when submitting the uploadform at least the worker get fired and > passed > the args as expected, as I can see in the backgroundrb_server.log: > > 20070201-10:47:29 (53830) Starting worker: image_worker upload_img > (image_worker_upload_img) > (imagecreated_on(2i)2created_on(3i)1created_on(4i)00created_on(5i) > 18updated_on(1i)2007updated_on(2i) > 2image_tempdescriptionbackgrounDRb33updated_on(3i) > 1imgnum007updated_on(4i)00image#updated_on(5i) > 18created_on(1i)2007) > > Now there are 2 questions: > > the image isnt uploaded, that is probably due to the fact that the > file_columnPlugin isnt available for the backgrounDRbserver.. > > My research turned out, that for the earlier version of the > backgrounDRb > you had to insert > > //require File.dirname(__FILE__) + "/../../config/environment.rb" > // > > in the scrip/backgroundrb/start script..there is no such script in the > actuall version and i cant see where to put that now. > > So, anyway, also if the image isnt uploaded physically shouldnt i > expect > at least an DB entry for the passed args as I call the save method on > @image ?? > > Further I think the dimension method should go also in the worker, but > step by step, and I am still totaly lost, so I just ask you kindly > again > to provide some input to enlighten me and others, as I guess that a > lot > of ppl are still missing some real world examples except of some > cronlike or outdated stuff > > best regards > > matthias > > > > > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From matthibcn at gmail.com Thu Feb 1 15:45:20 2007 From: matthibcn at gmail.com (matthibcn) Date: Thu, 01 Feb 2007 21:45:20 +0100 Subject: [Backgroundrb-devel] file_column 2nd try.... In-Reply-To: References: <45C23660.1080602@gmail.com> Message-ID: <45C25160.2000009@gmail.com> Hi Ezra, thank you very much for your reply as it saves me another few hours if not stays just get back my old working code ... and don?t try further. First of I was coming around your plugin for cornjobstuff and it works great, so one time installed and reading through the www about it I came also across various blogentries about it, and one mentioned that backgrounDRb is for much more than jst cronjobs as imageprocessing, massmailing ..and conclued: for everything what takes a bit longer So maybe i was misinterpreting this, my fault The progressbar wasnt the reason i tried with backgrounDRb, it was just a wild guess that it would be somewhat faster that way But, you are right, progressbars are like the state of the art today for imageuploading, so I am better of from backgrounDRb for that and spending my time in the mongrel_upload_progress gem for such feature Once again, thanks for the reply and the great plugin matthias Ezra Zygmuntowicz schrieb: > Hey there- > > I think you have a misconception of what backgroundrb can be used > for. There is no way to use backgroundrb to do a progress bar for a > file upload. Because the entire image will have to be uploaded before > rails will pass it to backgroundrb. > > Looking at your code I think you are better off not using > backgroundrb and just doing what you are doing all in rails. > > Is that your goal? TO have a progress bar for file uploads? If so > you are barking up the wrong tree sorry. You can look at the > mongrel_upload_progress gem to see about progress bars for file uploads. > > > Cheers- > -Ezra > > On Feb 1, 2007, at 10:50 AM, matthibcn wrote: > >> Looks like my first question a couple of days ago wasn?t very clever >> asked, at least very sucessfull.... >> >> So, anyway...i will try it again: >> >> I have to prefix that I am far away from fully understanding the overall >> concept yet, and there?s no way to get some hints in the www so far, at >> least my resaerches dont lead to any helpfull stuff. >> >> image_controller.rb: >> >> def create >> MiddleMan.new_worker :class => :image_worker, >> :job_key => :upload_img, >> :args => { :image => params[:image]} >> worker = ::MiddleMan.worker(:upload_img) >> end >> >> image_worker.rb >> >> require 'RMagick' >> >> class ImageWorker < BackgrounDRb::Worker::RailsBase >> >> ##attr_accessor :text >> >> def do_work(args) >> ##@text = args[:text] >> @image = Image.new(args[:image]) >> @image.dimensions >> @image.save >> end >> >> def progress >> results[:progress] >> end >> end >> ImageWorker.register >> >> image.rb >> >> require 'RMagick' >> >> class Image < ActiveRecord::Base >> belongs_to :user >> >> validates_filesize_of :image, :in => 15.kilobytes..1.megabyte >> validates_file_format_of :image, :in => ["gif", "png", "jpg"] >> >> file_column :image, :magick => {:versions => {"thumb" => "150x100", >> "picture" => "600x450>"}} >> >> def dimensions >> img = Magick::Image.read(self.image).first >> if img.columns >= img.rows >> ratio = img.columns.to_f / 600 >> else >> ratio = img.rows.to_f / 450 >> end >> self.width = ((img.columns / ratio)+10).to_i >> self.height = ((img.rows / ratio)+10).to_i >> end >> >> end >> >> So, this isn?t working...in fact I would be surprised if it would be >> that easy, as I just shifet code away from the controller to the >> worker... >> >> Ok: >> >> when submitting the uploadform at least the worker get fired and passed >> the args as expected, as I can see in the backgroundrb_server.log: >> >> 20070201-10:47:29 (53830) Starting worker: image_worker upload_img >> (image_worker_upload_img) >> (imagecreated_on(2i)2created_on(3i)1created_on(4i)00created_on(5i)18updated_on(1i)2007updated_on(2i)2image_tempdescriptionbackgrounDRb33updated_on(3i)1imgnum007updated_on(4i)00image#updated_on(5i)18created_on(1i)2007) >> >> >> Now there are 2 questions: >> >> the image isnt uploaded, that is probably due to the fact that the >> file_columnPlugin isnt available for the backgrounDRbserver.. >> >> My research turned out, that for the earlier version of the backgrounDRb >> you had to insert >> >> //require File.dirname(__FILE__) + "/../../config/environment.rb" >> // >> >> in the scrip/backgroundrb/start script..there is no such script in the >> actuall version and i cant see where to put that now. >> >> So, anyway, also if the image isnt uploaded physically shouldnt i expect >> at least an DB entry for the passed args as I call the save method on >> @image ?? >> >> Further I think the dimension method should go also in the worker, but >> step by step, and I am still totaly lost, so I just ask you kindly again >> to provide some input to enlighten me and others, as I guess that a lot >> of ppl are still missing some real world examples except of some >> cronlike or outdated stuff >> >> best regards >> >> matthias >> >> >> >> >> >> >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > -- Ezra Zygmuntowicz-- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > From bill.walton at charter.net Fri Feb 2 18:34:02 2007 From: bill.walton at charter.net (Bill Walton) Date: Fri, 2 Feb 2007 17:34:02 -0600 Subject: [Backgroundrb-devel] logging problem in production Message-ID: <02f901c74722$a0ea0560$6401a8c0@Presario> Greetings all; I've just moved my app into production and BackgrounDRb is writing to development.log. The backgroundrb.yml file specifies production, as does environment.rb. A little background (no pun intended ;-0 ) I'm using the 'old' version of backgroundrb for session management. In the app, whenever a visitor changes pages I record the time in a db record. In the worker, once a second, I'm doing a find for that record. Backgroundrb is logging that find in development.log, not in production.log as I expected. Anybody got any idea what I've done wrong? Thanks! Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070202/f7532abd/attachment.html From bill.walton at charter.net Sat Feb 3 13:33:05 2007 From: bill.walton at charter.net (Bill Walton) Date: Sat, 3 Feb 2007 12:33:05 -0600 Subject: [Backgroundrb-devel] logging problem in production References: <02f901c74722$a0ea0560$6401a8c0@Presario> Message-ID: <003a01c747c1$bee09d00$6401a8c0@Presario> An update: I have changed every reference I could find from 'development' to 'production'. I've also changed all references to 'localhost' to '127.0.0.1' as the support folks told me that using localhost in database.yml could cause me problems with MySQL. When I say all, I mean all. That includes the default settings in the start script. And BackgrounDRb is still logging the database selects being performed in the worker to the development.log file instead of production.log. Anybody? Thanks much in advance, Bill ----- Original Message ----- From: Bill Walton To: BackgroundRb Sent: Friday, February 02, 2007 5:34 PM Subject: [Backgroundrb-devel] logging problem in production Greetings all; I've just moved my app into production and BackgrounDRb is writing to development.log. The backgroundrb.yml file specifies production, as does environment.rb. A little background (no pun intended ;-0 ) I'm using the 'old' version of backgroundrb for session management. In the app, whenever a visitor changes pages I record the time in a db record. In the worker, once a second, I'm doing a find for that record. Backgroundrb is logging that find in development.log, not in production.log as I expected. Anybody got any idea what I've done wrong? Thanks! Bill ------------------------------------------------------------------------------ _______________________________________________ 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/20070203/57559fe6/attachment-0001.html From ezmobius at gmail.com Sat Feb 3 16:02:43 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Sat, 3 Feb 2007 13:02:43 -0800 Subject: [Backgroundrb-devel] logging problem in production In-Reply-To: <003a01c747c1$bee09d00$6401a8c0@Presario> References: <02f901c74722$a0ea0560$6401a8c0@Presario> <003a01c747c1$bee09d00$6401a8c0@Presario> Message-ID: <8C9C051D-F20D-4351-B82E-9A1C6D6A42ED@brainspl.at> Bill- I'm not sure why it is writing to the development log instead of production. But know this, calls to ActiveRecord objects in a worker will still write their sql to the normal rails log. The backgroundrb.log just logs errors and calls to @logger in a worker also log to the backgroundrb.log -Ezra On Feb 3, 2007, at 10:33 AM, Bill Walton wrote: > An update: > > I have changed every reference I could find from 'development' to > 'production'. I've also changed all references to 'localhost' to > '127.0.0.1' as the support folks told me that using localhost in > database.yml could cause me problems with MySQL. When I say all, I > mean all. That includes the default settings in the start script. > And BackgrounDRb is still logging the database selects being > performed in the worker to the development.log file instead of > production.log. > > Anybody? > > Thanks much in advance, > Bill > ----- Original Message ----- > From: Bill Walton > To: BackgroundRb > Sent: Friday, February 02, 2007 5:34 PM > Subject: [Backgroundrb-devel] logging problem in production > > Greetings all; > > I've just moved my app into production and BackgrounDRb is writing > to development.log. The backgroundrb.yml file specifies > production, as does environment.rb. > > A little background (no pun intended ;-0 ) I'm using the 'old' > version of backgroundrb for session management. In the app, > whenever a visitor changes pages I record the time in a db record. > In the worker, once a second, I'm doing a find for that record. > Backgroundrb is logging that find in development.log, not in > production.log as I expected. > > Anybody got any idea what I've done wrong? > > Thanks! > Bill > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From sweiss at stylesight.com Sat Feb 3 17:51:39 2007 From: sweiss at stylesight.com (Stephen Weiss) Date: Sat, 03 Feb 2007 17:51:39 -0500 Subject: [Backgroundrb-devel] Backgroundrb-devel Digest, Vol 9, Issue 1 In-Reply-To: References: Message-ID: Hi Bill, I have "version 1" backgroundrb running on my development server with rails 1.2.1, with no issues (other than the left over DB connections blocking up my MySQL server, which isn't exactly a new problem). Going to move production servers to rails 1.2.1 very soon, I'll post back if there's any trouble. Still would *really* like to get version 2 running though! Having a production system where I have to restart a process every couple hours is definitely *not* ideal but backgroundrb 2 is still completely unworkable for me. It still seg-faults every time I try to start a worker for the 2nd time (malloc error in drb.rb). Still can't get anything queue-based working because any call to worker_thread fails (nil:NilClass errors, totally following the docs and nothing...). This all on top of the fact that results worker doesn't really seem to hold any results. I've rewritten my software 8 different ways and no luck. I read that some people actually managed to get version 2 to work in production, I'd really love to know how. Has anyone gotten it to work successfully on Mac OS X 10.4, server or client, or anything close? I feel like it's gotta be something with gcc 4.x or the 64- bit-ness or ruby 1.8.5 or something, there are scattered clues all over google, but everything else on the system runs so well I'm really nervous to spend days recompiling everything down to 1.8.2/gcc 3.3 just to find out that everything else is broken but backgroundrb works fine. What really confuses me is I see very little chatter about these problems on the list or when searching the web, but I seriously can install a completely new 10.4 system, fresh ruby/rails/everything compiled from scratch, make a totally new Rails program, and plug in a worker straight from the examples that come with bgrb-2, and so help me when you run that worker the second time, it always seg- faults! Intel or PPC, server or client version, no difference! Just how does anyone with OS X get this running? Really, any advice at all... if someone with Mac OS X 10.4 has gotten version 2 to work, and you could just post all the version numbers on the gcc, ruby, etc that you use with it, my database, my users and I would be so very grateful. -- Steve On Feb 3, 2007, at 1:33 PM, backgroundrb-devel-request at rubyforge.org wrote: > > Greetings! > > Has anybody tried running the 'old' version of BackgrouDRb (the > repository on rubyforge.org) on Rails 1.2.1? Any reason to think > it won't work? > > Thanks! > Bill > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/ > 20070130/93d4cd89/attachment-0001.html > > ------------------------------ > From eimorton at gmail.com Sat Feb 3 18:34:45 2007 From: eimorton at gmail.com (Erik Morton) Date: Sat, 3 Feb 2007 18:34:45 -0500 Subject: [Backgroundrb-devel] Backgroundrb-devel Digest, Vol 9, Issue 1 In-Reply-To: References: Message-ID: <7256A6B4-B7B0-4014-9834-99A984213755@gmail.com> I have no such problems on OS X 10.4.8 and Rails 1.1.6 Here is my configuration: erik$ ruby -v ruby 1.8.4 (2005-12-24) [i686-darwin8.6.1] erik$ gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure -- disable-checking -enable-werror --prefix=/usr --mandir=/share/man -- enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg] [^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 -- build=powerpc-apple-darwin8 --with-arch=pentium-m --with- tune=prescott --program-prefix= --host=i686-apple-darwin8 -- target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5250) erik$ uname -a Darwin erik.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 erik$ gem list|grep slave slave (1.2.0) erik$ gem list|grep daemons daemons (1.0.3) On Feb 3, 2007, at 5:51 PM, Stephen Weiss wrote: > Hi Bill, > > I have "version 1" backgroundrb running on my development server with > rails 1.2.1, with no issues (other than the left over DB connections > blocking up my MySQL server, which isn't exactly a new problem). > Going to move production servers to rails 1.2.1 very soon, I'll post > back if there's any trouble. > > Still would *really* like to get version 2 running though! Having a > production system where I have to restart a process every couple > hours is definitely *not* ideal but backgroundrb 2 is still > completely unworkable for me. It still seg-faults every time I try > to start a worker for the 2nd time (malloc error in drb.rb). Still > can't get anything queue-based working because any call to > worker_thread fails (nil:NilClass errors, totally following the docs > and nothing...). This all on top of the fact that results worker > doesn't really seem to hold any results. I've rewritten my software > 8 different ways and no luck. > > I read that some people actually managed to get version 2 to work in > production, I'd really love to know how. Has anyone gotten it to > work successfully on Mac OS X 10.4, server or client, or anything > close? I feel like it's gotta be something with gcc 4.x or the 64- > bit-ness or ruby 1.8.5 or something, there are scattered clues all > over google, but everything else on the system runs so well I'm > really nervous to spend days recompiling everything down to 1.8.2/gcc > 3.3 just to find out that everything else is broken but backgroundrb > works fine. > > What really confuses me is I see very little chatter about these > problems on the list or when searching the web, but I seriously can > install a completely new 10.4 system, fresh ruby/rails/everything > compiled from scratch, make a totally new Rails program, and plug in > a worker straight from the examples that come with bgrb-2, and so > help me when you run that worker the second time, it always seg- > faults! Intel or PPC, server or client version, no difference! Just > how does anyone with OS X get this running? > > Really, any advice at all... if someone with Mac OS X 10.4 has > gotten version 2 to work, and you could just post all the version > numbers on the gcc, ruby, etc that you use with it, my database, my > users and I would be so very grateful. > > -- > Steve > > > On Feb 3, 2007, at 1:33 PM, backgroundrb-devel-request at rubyforge.org > wrote: >> >> Greetings! >> >> Has anybody tried running the 'old' version of BackgrouDRb (the >> repository on rubyforge.org) on Rails 1.2.1? Any reason to think >> it won't work? >> >> Thanks! >> Bill >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/ >> 20070130/93d4cd89/attachment-0001.html >> >> ------------------------------ >> > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From ezmobius at gmail.com Sat Feb 3 18:46:57 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Sat, 3 Feb 2007 15:46:57 -0800 Subject: [Backgroundrb-devel] Backgroundrb-devel Digest, Vol 9, Issue 1 In-Reply-To: References: Message-ID: <2D0E8E77-B09E-41C5-9C40-BF3CDD96693E@brainspl.at> Hey~ On Feb 3, 2007, at 2:51 PM, Stephen Weiss wrote: > Hi Bill, > > I have "version 1" backgroundrb running on my development server with > rails 1.2.1, with no issues (other than the left over DB connections > blocking up my MySQL server, which isn't exactly a new problem). > Going to move production servers to rails 1.2.1 very soon, I'll post > back if there's any trouble. In version 1 of the plugin you need to call ActiveRecord::Base.connection.disconnect! as the last thing your worker does or when it's done with the database. This will not affect the other db handles as it only disconnects the db handle for the thread your worker is running in. > > Really, any advice at all... if someone with Mac OS X 10.4 has > gotten version 2 to work, and you could just post all the version > numbers on the gcc, ruby, etc that you use with it, my database, my > users and I would be so very grateful. > > -- > Steve ez ez $ ruby -v ruby 1.8.5 (2006-08-25) [i686-darwin8.7.1] ez ez $ gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure -- disable-checking -enable-werror --prefix=/usr --mandir=/share/man -- enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg] [^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with- slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=nocona -- with-tune=generic --program-prefix= --host=i686-apple-darwin8 -- target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5363) ez ez $ uname -a Darwin ezra-zygmuntowiczs-computer.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/ RELEASE_I386 i386 i386 ez ez $ gem list slave *** LOCAL GEMS *** slave (1.2.0, 1.0.0) slave ez ez $ gem list daemons *** LOCAL GEMS *** daemons (1.0.3, 1.0.2, 0.4.2) A toolkit to create and control daemons in different ways Sorry you are having trouble Steve. Admitedly Backgroundrb0.2.x branch does still have some problems but it does work very well once you tame it. That being said I have had zero time to work on bdrb in the last few months./ skaar did a ton of great work on this new architecture. But he and I have always said that 0.3.x will be the stable release of the new architecture. I hope to have some time soon to go over the 0.2.x branch and fix any issues people are having. I also think that the old way of doing jobs has its place. So I may release a trimmed down refactored version of the original plugin. The thrteaded approach is fast to spawn jobs and if you are doing small tasks like cleaning sessions and working with rss of csv files then the old way is faster to spawn workers. The new slave architecture is for higher volume processing with long lived workers. All that being said, if anyone wants to step up and help fix problems with either version of the plugin then I welcome you and I love patches ;) Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From bill.walton at charter.net Sun Feb 4 12:27:21 2007 From: bill.walton at charter.net (Bill Walton) Date: Sun, 4 Feb 2007 11:27:21 -0600 Subject: [Backgroundrb-devel] Backgroundrb-devel Digest, Vol 9, Issue 1 References: <2D0E8E77-B09E-41C5-9C40-BF3CDD96693E@brainspl.at> Message-ID: <001801c74881$ba4bf670$6401a8c0@Presario> Hi Ezra, Ezra Zygmuntowicz wrote: > I also think that the old way of doing jobs has > its place. So I may release a trimmed down > refactored version of the original plugin. The > thrteaded approach is fast to spawn jobs and > if you are doing small tasks like cleaning sessions I'm really glad to hear you take this position. > All that being said, if anyone wants to step up > and help fix problems with either version of the > plugin then I welcome you and I love patches ;) Count me in. I'm not sure just how helpful I'll be, but I'm definitely going to have to figure out what's going wrong in my situation and get it fixed. More on my situation in the other thread. Thanks, Bill From bill.walton at charter.net Sun Feb 4 12:48:10 2007 From: bill.walton at charter.net (Bill Walton) Date: Sun, 4 Feb 2007 11:48:10 -0600 Subject: [Backgroundrb-devel] logging problem in production References: <02f901c74722$a0ea0560$6401a8c0@Presario> <003a01c747c1$bee09d00$6401a8c0@Presario> <8C9C051D-F20D-4351-B82E-9A1C6D6A42ED@brainspl.at> Message-ID: <000201c74885$dba2fa90$6401a8c0@Presario> Hi Ezra, Ezra Zygmuntowicz wrote: > I'm not sure why it is writing to the development log instead of > production. But know this, calls to ActiveRecord objects in a worker will > still write their sql to the normal rails log. I went to bed last night believing firmly that the problem I'm having lay with my hosted environment and comitted fully to figuring out how to conclusively demonstrate that to them. I woke this morning with a plan, but also realizing that I'd missed an important step in my debugging efforts so far. Everything works fine on my development box in development mode. But I hadn't tested the behavior on my development box in *production* mode. There is definitely a problem with Backgroundrb in production mode. I am seeing *exactly* the same behavior on my local machine that I'm seeing on my hosted environment. In development mode, everything gets written to development.log. In production mode, the web server logging goes to production.log. But the SQL logging, and not all of it, goes to the development log. From bill.walton at charter.net Sun Feb 4 13:05:37 2007 From: bill.walton at charter.net (Bill Walton) Date: Sun, 4 Feb 2007 12:05:37 -0600 Subject: [Backgroundrb-devel] logging problem in production Message-ID: <000701c74887$204228a0$6401a8c0@Presario> Oops... I wasn't done. Dang fat fingers ;-) Bill Walton wrote > Hi Ezra, > > Ezra Zygmuntowicz wrote: > >> I'm not sure why it is writing to the development log instead of >> production. But know this, calls to ActiveRecord objects in a worker will >> still write their sql to the normal rails log. > > I went to bed last night believing firmly that the problem I'm having lay > with my hosted environment and comitted fully to figuring out how to > conclusively demonstrate that to them. > > I woke this morning with a plan, but also realizing that I'd missed an > important step in my debugging efforts so far. Everything works fine on > my development box in development mode. But I hadn't tested the behavior > on my development box in *production* mode. > > There is definitely a problem with Backgroundrb in production mode. > > I am seeing *exactly* the same behavior on my local machine that I'm > seeing on my hosted environment. In development mode, everything gets > written to development.log. In production mode, the web server logging > goes to production.log. But the SQL logging, and not all of it, goes to > the development log. The piece of the app that I'm testing is trivial in terms of size. I'll send a zip to anyone willing to help by giving it a run on their system. Along, of course, with my eternal gratitude! Best regards to all, Bill From jonesieboy at gmail.com Sun Feb 4 14:38:14 2007 From: jonesieboy at gmail.com (Robert Jones) Date: Sun, 4 Feb 2007 19:38:14 +0000 Subject: [Backgroundrb-devel] Can BackgrounDrb help me? Message-ID: <691b0e0a0702041138j54c08878n1ac46b0bc6ad390c@mail.gmail.com> I have a big report to produce from a Rails app that takes several minutes to put together. I hoped backgroundrb would be able to pull together all the ActiveRecord stuff in the background then throw it back to Rails for rendering. It seems, however, that I can't pass an array of ActiveRecord objects from the worker back to Rails. Do I have that right? Another possibility was to do the rendering in the worker and send back a text variable. I got erb rendering working thanks to the tips from Jacob Robbins, but none of the ActionView helpers like "image_tag" are recognised. Can anyone tell me how to make that happen? Any suggestions gratefully received. Robert Jones http://www.jonesieboy.co.uk/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070204/0d70ec5e/attachment-0001.html From masonhale at gmail.com Sun Feb 4 14:48:46 2007 From: masonhale at gmail.com (Mason Hale) Date: Sun, 4 Feb 2007 13:48:46 -0600 Subject: [Backgroundrb-devel] Can BackgrounDrb help me? In-Reply-To: <691b0e0a0702041138j54c08878n1ac46b0bc6ad390c@mail.gmail.com> References: <691b0e0a0702041138j54c08878n1ac46b0bc6ad390c@mail.gmail.com> Message-ID: <8bca3aa10702041148p6b84a236u5d7de33fe43e3551@mail.gmail.com> Hi Robert -- Can you elaborate a bit on what you are trying to do, exactly? What do you mean by "ActiveRecord stuff"? Mason On 2/4/07, Robert Jones wrote: > > I have a big report to produce from a Rails app that takes several minutes > to put together. I hoped backgroundrb would be able to pull together all > the ActiveRecord stuff in the background then throw it back to Rails for > rendering. > > It seems, however, that I can't pass an array of ActiveRecord objects from > the worker back to Rails. Do I have that right? > > Another possibility was to do the rendering in the worker and send back a > text variable. I got erb rendering working thanks to the tips from Jacob > Robbins, but none of the ActionView helpers like "image_tag" are > recognised. Can anyone tell me how to make that happen? > > Any suggestions gratefully received. > > Robert Jones > http://www.jonesieboy.co.uk/blog > > > > _______________________________________________ > 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/20070204/9c124df9/attachment.html From ezmobius at gmail.com Sun Feb 4 14:57:04 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Sun, 4 Feb 2007 11:57:04 -0800 Subject: [Backgroundrb-devel] Can BackgrounDrb help me? In-Reply-To: <691b0e0a0702041138j54c08878n1ac46b0bc6ad390c@mail.gmail.com> References: <691b0e0a0702041138j54c08878n1ac46b0bc6ad390c@mail.gmail.com> Message-ID: On Feb 4, 2007, at 11:38 AM, Robert Jones wrote: > I have a big report to produce from a Rails app that takes several > minutes to put together. I hoped backgroundrb would be able to > pull together all the ActiveRecord stuff in the background then > throw it back to Rails for rendering. > > It seems, however, that I can't pass an array of ActiveRecord > objects from the worker back to Rails. Do I have that right? > > Another possibility was to do the rendering in the worker and send > back a text variable. I got erb rendering working thanks to the > tips from Jacob Robbins, but none of the ActionView helpers like > "image_tag" are recognised. Can anyone tell me how to make that > happen? > > Any suggestions gratefully received. > > Robert Jones > http://www.jonesieboy.co.uk/blog > Robert- It is best to avoid sending large objects or strings back and forth between rails and bdrb because whatever you send across has to be marshalled and unmarshalled. I think you would be better off if you had bdrb save the array of AR objects back into the database and then have drb send back an array of id's of those objects. Then in rails you can grab them from the db again and render. Bdrb does not have access to rails controllers or views in the normal way that rails does because it is not taking HTTP requests. You are better off having bdrb do the heavy lifting and then let rails do the rendering. But try to keep the objects you pass back and forth as small as possible. -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From jerrod at indierockmedia.com Mon Feb 5 13:48:14 2007 From: jerrod at indierockmedia.com (Jerrod Blavos) Date: Mon, 5 Feb 2007 13:48:14 -0500 Subject: [Backgroundrb-devel] Deploying to production with backgroundrb (capistrano) Message-ID: I have noticed that occasionally (about 50% of the time) when i deploy (using capistrano) my app to a production server, i have to ssh into the box and manually stop and start backgroundrb to get it to load my workers. this is my basic setup i have 2 workers: lib/workers/mp3_worker.rb => takes a hash of params to downsample an mp3 lib/workers/flv_worker.rb => takes a has of arguments to compose a command line to convert a file into flv in my recipe config/deploy.rb i have 2 lines run "#{current_path}/script/backgroundrb stop" run "#{current_path}/script/backgroundrb start" that should stop the server and restart it. after the deploy, i have started sshing in tot he box and running script/backgroundrb console and checking the loaded_worker_classes about 50% of the time, its empty. no classes loaded. if i manually run those commands, it starts and they load. identical command. different (and upredictable) results. how would i go about ensuring that when i deploy that backgroundrb restarts properly? ideally i will only be restarting backgroundrb when i have model changes or worker class changes that would affect it's operation. Jerrod Blavos ph. 919.341.0143 fx. 482.492.5009 jerrod at indierockmedia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070205/1463d282/attachment.html From ezmobius at gmail.com Mon Feb 5 14:22:10 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Mon, 5 Feb 2007 11:22:10 -0800 Subject: [Backgroundrb-devel] Deploying to production with backgroundrb (capistrano) In-Reply-To: References: Message-ID: Hey Jerrod- You need to use nohup in your tasks to start bdrb. task :before_restart, :roles => :app do restart_backgroundrb end task :start_backgroundrb, :roles => :app do sudo "nohup /data/#{application}/current/script/backgroundrb start " end task :stop_backgroundrb, :roles => :app do sudo "kill -9 `cat /data/#{application}/current/log/ backgroundrb.pid` 2>/dev/null; true" end task :restart_backgroundrb, :roles => :app do stop_backgroundrb start_backgroundrb end Cheers- -Ezra On Feb 5, 2007, at 10:48 AM, Jerrod Blavos wrote: > I have noticed that occasionally (about 50% of the time) when i > deploy (using capistrano) my app to a production server, i have to > ssh into the box and manually > stop and start backgroundrb to get it to load my workers. > > this is my basic setup > > i have 2 workers: > > lib/workers/mp3_worker.rb => takes a hash of params to downsample > an mp3 > lib/workers/flv_worker.rb => takes a has of arguments to compose > a command line to convert a file into flv > > in my recipe > config/deploy.rb > > i have 2 lines > run "#{current_path}/script/backgroundrb stop" > run "#{current_path}/script/backgroundrb start" > > that should stop the server and restart it. > > after the deploy, i have started sshing in tot he box and running > > script/backgroundrb console > > and checking the loaded_worker_classes > > about 50% of the time, its empty. no classes loaded. > > if i manually run those commands, it starts and they load. > identical command. different (and upredictable) results. > > how would i go about ensuring that when i deploy that backgroundrb > restarts properly? ideally i will only be restarting backgroundrb > when i have model changes or worker class changes that would affect > it's operation. > > > Jerrod Blavos > ph. 919.341.0143 > fx. 482.492.5009 > jerrod at indierockmedia.com > > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From jerrod at indierockmedia.com Mon Feb 5 13:48:14 2007 From: jerrod at indierockmedia.com (Jerrod Blavos) Date: Mon, 5 Feb 2007 13:48:14 -0500 Subject: [Backgroundrb-devel] Deploying to production with backgroundrb (capistrano) Message-ID: I have noticed that occasionally (about 50% of the time) when i deploy (using capistrano) my app to a production server, i have to ssh into the box and manually stop and start backgroundrb to get it to load my workers. this is my basic setup i have 2 workers: lib/workers/mp3_worker.rb => takes a hash of params to downsample an mp3 lib/workers/flv_worker.rb => takes a has of arguments to compose a command line to convert a file into flv in my recipe config/deploy.rb i have 2 lines run "#{current_path}/script/backgroundrb stop" run "#{current_path}/script/backgroundrb start" that should stop the server and restart it. after the deploy, i have started sshing in tot he box and running script/backgroundrb console and checking the loaded_worker_classes about 50% of the time, its empty. no classes loaded. if i manually run those commands, it starts and they load. identical command. different (and upredictable) results. how would i go about ensuring that when i deploy that backgroundrb restarts properly? ideally i will only be restarting backgroundrb when i have model changes or worker class changes that would affect it's operation. Jerrod Blavos ph. 919.341.0143 fx. 482.492.5009 jerrod at indierockmedia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070205/1463d282/attachment-0001.html From jerrod at indierockmedia.com Mon Feb 5 15:12:58 2007 From: jerrod at indierockmedia.com (Jerrod Blavos) Date: Mon, 5 Feb 2007 15:12:58 -0500 Subject: [Backgroundrb-devel] Deploying with capistrano issue. Resolution ! Message-ID: <3797942E-E825-4B38-8C40-DBC109D25EF0@indierockmedia.com> ok, i was wrong. the failure on deployment using capistrano is 100% using these commands ## Our Handlers desc "Restart BackgrounDrb" task :restart_uploader, :roles => :app do run "#{current_path}/script/backgroundrb stop" run "#{current_path}/script/backgroundrb start" end here is the console post deploy on the remote server ######## [current]$ script/backgroundrb console irb: warn: can't alias jobs from irb_jobs. irb(#):001:0> loaded_worker_classes => [] irb(#):002:0> exit Now ill stop it and start it again on the remote server ######## [current]$ script/backgroundrb stop [current]$ script/backgroundrb start [current]$ script/backgroundrb console irb: warn: can't alias jobs from irb_jobs. irb(#):001:0> loaded_worker_classes => ["Mp3Worker", "FlvWorker"] i DID find however that the following worked. seems i HAVE to be in the current directory in order for it to start properly. maybe this will help in tracking down the issue? desc "Restart BackgrounDrb" task :restart_backgroundrb, :roles => :app do run "cd #{current_path} && script/backgroundrb stop" run "cd #{current_path} && script/backgroundrb start" end Jerrod Blavos ph. 919.341.0143 fx. 482.492.5009 jerrod at indierockmedia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070205/44e360df/attachment-0001.html From jrobbins at cmj.com Tue Feb 6 12:50:13 2007 From: jrobbins at cmj.com (Jacob Robbins) Date: Tue, 06 Feb 2007 12:50:13 -0500 Subject: [Backgroundrb-devel] logging problem in production In-Reply-To: <000701c74887$204228a0$6401a8c0@Presario> References: <000701c74887$204228a0$6401a8c0@Presario> Message-ID: <45C8BFD5.9070103@cmj.com> Bill, Have you made any progress on your logging issue? From what i've seen on the list this could just as likely be a backgroundrb issue as something in your app. Backgroundrb still has many corner cases where it doesn't handle the RAILS_ENV variable correctly. I wouldn't be surprised if it is doing this for everybody but nobody else has been bothered enough/noticed it to report it to the list. If you do identify the location of the problem and it's in bdrb please take the time to add it to the backgroundrb trac. Have you tried creating an empty rails app, adding backgroundrb and your worker, then using the bdrb console in production mode? -Jacob Bill Walton wrote: > Oops... I wasn't done. Dang fat fingers ;-) > > Bill Walton wrote > >> Hi Ezra, >> >> Ezra Zygmuntowicz wrote: >> >>> I'm not sure why it is writing to the development log instead of >>> production. But know this, calls to ActiveRecord objects in a worker will >>> still write their sql to the normal rails log. >> I went to bed last night believing firmly that the problem I'm having lay >> with my hosted environment and comitted fully to figuring out how to >> conclusively demonstrate that to them. >> >> I woke this morning with a plan, but also realizing that I'd missed an >> important step in my debugging efforts so far. Everything works fine on >> my development box in development mode. But I hadn't tested the behavior >> on my development box in *production* mode. >> >> There is definitely a problem with Backgroundrb in production mode. >> >> I am seeing *exactly* the same behavior on my local machine that I'm >> seeing on my hosted environment. In development mode, everything gets >> written to development.log. In production mode, the web server logging >> goes to production.log. But the SQL logging, and not all of it, goes to >> the development log. > > The piece of the app that I'm testing is trivial in terms of size. I'll > send a zip to anyone willing to help by giving it a run on their system. > Along, of course, with my eternal gratitude! > > Best regards to all, > Bill > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From ezmobius at gmail.com Tue Feb 6 14:05:23 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Tue, 6 Feb 2007 11:05:23 -0800 Subject: [Backgroundrb-devel] logging problem in production In-Reply-To: <45C8BFD5.9070103@cmj.com> References: <000701c74887$204228a0$6401a8c0@Presario> <45C8BFD5.9070103@cmj.com> Message-ID: <4B640070-AD8E-42DE-B5E9-BC834143D9B5@brainspl.at> Yeah Bill solved his problem, he just needed to set RAILS_ENV=production as an env var when starting up backgroundrb. -Ezra On Feb 6, 2007, at 9:50 AM, Jacob Robbins wrote: > Bill, > Have you made any progress on your logging issue? > > From what i've seen on the list this could just as likely be a > backgroundrb issue as something in your app. Backgroundrb still has > many > corner cases where it doesn't handle the RAILS_ENV variable > correctly. I > wouldn't be surprised if it is doing this for everybody but nobody > else has been bothered enough/noticed it to report it to the list. > > If you do identify the location of the problem and it's in bdrb > please > take the time to add it to the backgroundrb trac. > > Have you tried creating an empty rails app, adding backgroundrb and > your worker, then using the bdrb console in production mode? > > -Jacob > > Bill Walton wrote: >> Oops... I wasn't done. Dang fat fingers ;-) >> >> Bill Walton wrote >> >>> Hi Ezra, >>> >>> Ezra Zygmuntowicz wrote: >>> >>>> I'm not sure why it is writing to the development log instead of >>>> production. But know this, calls to ActiveRecord objects in a >>>> worker will >>>> still write their sql to the normal rails log. >>> I went to bed last night believing firmly that the problem I'm >>> having lay >>> with my hosted environment and comitted fully to figuring out how to >>> conclusively demonstrate that to them. >>> >>> I woke this morning with a plan, but also realizing that I'd >>> missed an >>> important step in my debugging efforts so far. Everything works >>> fine on >>> my development box in development mode. But I hadn't tested the >>> behavior >>> on my development box in *production* mode. >>> >>> There is definitely a problem with Backgroundrb in production mode. >>> >>> I am seeing *exactly* the same behavior on my local machine that I'm >>> seeing on my hosted environment. In development mode, everything >>> gets >>> written to development.log. In production mode, the web server >>> logging >>> goes to production.log. But the SQL logging, and not all of it, >>> goes to >>> the development log. >> >> The piece of the app that I'm testing is trivial in terms of >> size. I'll >> send a zip to anyone willing to help by giving it a run on their >> system. >> Along, of course, with my eternal gratitude! >> >> Best regards to all, >> Bill >> >> >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From mark at martianrover.com Tue Feb 6 14:22:47 2007 From: mark at martianrover.com (P. Mark Anderson) Date: Tue, 06 Feb 2007 11:22:47 -0800 Subject: [Backgroundrb-devel] Deploying with capistrano issue. Resolution! In-Reply-To: <3797942E-E825-4B38-8C40-DBC109D25EF0@indierockmedia.com> References: <3797942E-E825-4B38-8C40-DBC109D25EF0@indierockmedia.com> Message-ID: <45C8D587.3060106@martianrover.com> Somewhat related to the deployment issue, I like to make sure Backgroundrb is ready before launching workers and that's what this code does. It lives in my ApplicationController. pmark # # Confirm Backgroundrb is running and start if dead. # def prepare_backgroundrb begin # try to contact Backgroundrb in some way MiddleMan.gc!((Time.now-10.years).to_time) rescue begin `cd #{RAILS_ROOT} && script/backgroundrb start` sleep(10) rescue log.error("unable to start Backgroundrb: #{$!}") end end end From bill.walton at charter.net Tue Feb 6 18:12:05 2007 From: bill.walton at charter.net (Bill Walton) Date: Tue, 6 Feb 2007 17:12:05 -0600 Subject: [Backgroundrb-devel] logging problem in production References: <000701c74887$204228a0$6401a8c0@Presario> <45C8BFD5.9070103@cmj.com> Message-ID: <012d01c74a44$3b2a54d0$6401a8c0@Presario> Hi Jacob, Jacob Robbins wrote: > Have you made any progress on your logging issue? Sorry for my delay in responding. I've had my email shut down most of the day. Sometimes very wierd things start happening when Outlook starts receiving during a testing session. As Ezra has already responded with the broad stroke, I'll just add a little detail. Eden Li was actually the first to suggest the solution. It didn't show up here because he hit the 'Reply' button instead of the 'Reply All'. (I really hate how that varies from list to list). In my Linux environment, I'm now invoking Backgroundrb using: $ RAILS_ENV=production script/backgroundrb/start -d Note that I've used the -d option so I could get the command prompt back to start mongrel from the same PuTTY session. If that's going to cause me a problem down the road, someone _please_ let me know. ----------------- If anyone can help me understand why the following does not work, I'd be very appreciative. $ RAILS_ENV=production $ rake backgroundrb:start ----------------- On Windows, where I'm doing my development, things are a little trickier. A Command Window doesn't give you access to the System's version of the Environment Variables. Any value set in a Command Window is only available in that window. That's been true since at least Win2K, and I'm pretty sure it started with NT. So I set RAILS_ENV in My Computer -> Properties -> Advanced -> Environment Variables. Best regards, Bill From ciudica at gmail.com Wed Feb 7 04:33:24 2007 From: ciudica at gmail.com (Gabi Ciudoiu) Date: Wed, 7 Feb 2007 11:33:24 +0200 Subject: [Backgroundrb-devel] ncluding backgroundrb issue Message-ID: I have the next including files structure : - controller fileaA.rb including line (#8): require "fileB"... - /lib/fileB.rb with main header: load 'backgroundrb/worker.rb' load 'backgroundrb/ worker_rails.rb' class FileB < BackgrounDRb::Worker::RailsBase ........................................................................ and on line #72: FileB .register when I restart my lighttpd web server , at the first loading of the controller it rise the next error: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occured while evaluating nil.include? RAILS_ROOT: ...... Application Trace | Framework Trace | Full Trace #{RAILS_ROOT}*/vendor/plugins/backgroundrb/server/lib/backgroundrb/* middleman.rb:158:in `register_worker_class' #{RAILS_ROOT}*/vendor/plugins/backgroundrb/server/lib/backgroundrb/* worker.rb:17:in `register' #{RAILS_ROOT}/lib/fileB.rb:72 #{RAILS_ROOT}/app/controllers/fileA.rb:8 After reloading the page, this error did not rise again , I need help with any idea concerning this behavior of backgroundrb plugin (what is wrong in my including code or what could generate this error?) Thank's -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070207/0fd9588b/attachment.html From skaar at waste.org Wed Feb 7 06:18:06 2007 From: skaar at waste.org (skaar) Date: Wed, 7 Feb 2007 05:18:06 -0600 Subject: [Backgroundrb-devel] ncluding backgroundrb issue In-Reply-To: References: Message-ID: <20070207111806.GA7244@waste.org> I'm not quite sure what you are trying to do here - are you trying to require a file with a BackgrounDRb worker class in your Rails controller? In that case - that's just not how it works. The BackgrouDRb worker classes need the backgroundrb server process. Take a look at the documentation again. /skaar * Gabi Ciudoiu (ciudica at gmail.com) [070207 03:59]: > I have the next including files structure : > > - controller fileaA.rb including line (#8): require "fileB"... > - /lib/fileB.rb with main header: load 'backgroundrb/worker.rb' > load 'backgroundrb/ > worker_rails.rb' > class FileB < > BackgrounDRb::Worker::RailsBase > ........................................................................ > and on line #72: FileB .register > when I restart my lighttpd web server , at the first loading of the > controller it rise the next error: > > You have a nil object when you didn't expect it! > You might have expected an instance of Array. > > The error occured while evaluating nil.include? > > RAILS_ROOT: ...... > Application Trace | Framework Trace | Full Trace > > #{RAILS_ROOT}/vendor/plugins/backgroundrb/server/lib/backgroundrb > / > middleman.rb:158:in `register_worker_class' > #{RAILS_ROOT}/vendor/plugins/backgroundrb/server/lib/backgroundrb > / > worker.rb:17:in `register' > #{RAILS_ROOT}/lib/fileB.rb:72 > #{RAILS_ROOT}/app/controllers/fileA.rb:8 > > After reloading the page, this error did not rise again , I need help > with any idea concerning this behavior of backgroundrb plugin (what is > wrong in my including code or what could generate this error?) > > Thank's > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel -- ---------------------------------------------------------------------- |\|\ where in the | s_u_b_s_t_r_u_c_t_i_o_n | | >=========== W.A.S.T.E. | genarratologies |/|/ (_) is the wisdom | skaar at waste.org ---------------------------------------------------------------------- From ciudica at gmail.com Wed Feb 7 07:06:30 2007 From: ciudica at gmail.com (Gabi Ciudoiu) Date: Wed, 7 Feb 2007 14:06:30 +0200 Subject: [Backgroundrb-devel] ncluding backgroundrb issue In-Reply-To: <20070207111806.GA7244@waste.org> References: <20070207111806.GA7244@waste.org> Message-ID: Thank you, you are right it was my mistake to require the worker class in my controller, I did not know that the file will be "included" by MiddleMan.new_worker and no need of require ; now it is ok. Gabriel On 2/7/07, skaar wrote: > > I'm not quite sure what you are trying to do here - are you trying to > require a file with a BackgrounDRb worker class in your Rails > controller? In that case - that's just not how it works. The BackgrouDRb > worker classes need the backgroundrb server process. Take a look at the > documentation again. > > /skaar > > > * Gabi Ciudoiu (ciudica at gmail.com) [070207 03:59]: > > I have the next including files structure : > > > > - controller fileaA.rb including line (#8): require "fileB"... > > - /lib/fileB.rb with main header: load 'backgroundrb/worker.rb' > > load 'backgroundrb/ > > worker_rails.rb' > > class FileB < > > BackgrounDRb::Worker::RailsBase > > > ........................................................................ > > and on line #72: FileB .register > > when I restart my lighttpd web server , at the first loading of the > > controller it rise the next error: > > > > You have a nil object when you didn't expect it! > > You might have expected an instance of Array. > > > > The error occured while evaluating nil.include? > > > > RAILS_ROOT: ...... > > Application Trace | Framework Trace | Full Trace > > > > #{RAILS_ROOT}/vendor/plugins/backgroundrb/server/lib/backgroundrb > > / > > middleman.rb:158:in `register_worker_class' > > #{RAILS_ROOT}/vendor/plugins/backgroundrb/server/lib/backgroundrb > > / > > worker.rb:17:in `register' > > #{RAILS_ROOT}/lib/fileB.rb:72 > > #{RAILS_ROOT}/app/controllers/fileA.rb:8 > > > > After reloading the page, this error did not rise again , I need help > > with any idea concerning this behavior of backgroundrb plugin (what is > > wrong in my including code or what could generate this error?) > > > > Thank's > > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > -- > ---------------------------------------------------------------------- > |\|\ where in the | s_u_b_s_t_r_u_c_t_i_o_n > | | >=========== W.A.S.T.E. | genarratologies > |/|/ (_) is the wisdom | skaar at waste.org > ---------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070207/db693a5e/attachment-0001.html From maillist at steelskies.com Wed Feb 7 08:45:38 2007 From: maillist at steelskies.com (Jonathan del Strother) Date: Wed, 7 Feb 2007 13:45:38 +0000 Subject: [Backgroundrb-devel] Repeatedly dying with "failed to find slave socket" Message-ID: I'm struggling to keep backgroundrb v2 running for more than 24 hours. It appears to be running fine for a while, then tries to fire off a worker (exactly the same worker it's been running for the past few hours), and it suddenly dies. I haven't found any pattern for the cause of this. In backgroundrb_server.log, the final entry is this : 20070206-10:41:45 (5189) Schedule triggered: # job=#, trigger=#, earliest=Tue Feb 06 10:41:45 -0800 2007, last=Tue Feb 06 10:41:45 -0800 2007> 20070206-10:41:45 (5189) failed to find slave socket - (RuntimeError) 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/slave-1.2.0/lib/ slave.rb:435:in `initialize' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/middleman.rb:210:in `new' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/middleman.rb:210:in `new_worker' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/thread_pool.rb:36:in `dispatch' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/thread_pool.rb:22:in `initialize' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/thread_pool.rb:22:in `new' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/thread_pool.rb:22:in `dispatch' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/middleman.rb:199:in `new_worker' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/middleman.rb:357:in `schedule_worker' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/scheduler.rb:46:in `call' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/scheduler.rb:46:in `run' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/scheduler.rb:40:in `each' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/scheduler.rb:40:in `run' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/scheduler.rb:35:in `loop' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/scheduler.rb:35:in `run' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/scheduler.rb:95:in `run' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/scheduler.rb:94:in `initialize' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/scheduler.rb:94:in `new' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/scheduler.rb:94:in `run' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb/middleman.rb:106:in `setup' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb_server.rb:306:in `run' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons/application.rb:186:in `call' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons/application.rb:186:in `start_proc' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons/daemonize.rb:192:in `call' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons/daemonize.rb:192:in `call_as_daemon' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons/application.rb:190:in `start_proc' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons/application.rb:226:in `start' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons/controller.rb:69:in `run' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons.rb:182:in `run_proc' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons/cmdline.rb:94:in `call' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons/cmdline.rb:94:in `catch_exceptions' 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ lib/daemons.rb:181:in `run_proc' 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ backgroundrb_server.rb:301:in `run' 20070206-10:41:45 (5189) .../script/backgroundrb:29 This happens both on my EngineYard server, and running locally on intel OS X 10.4.8. Any suggestions? Anyone else experiencing this? Jon From masonhale at gmail.com Wed Feb 7 11:16:48 2007 From: masonhale at gmail.com (Mason Hale) Date: Wed, 7 Feb 2007 10:16:48 -0600 Subject: [Backgroundrb-devel] Repeatedly dying with "failed to find slave socket" In-Reply-To: References: Message-ID: <8bca3aa10702070816o68a1cd11x463567a0a7fb610@mail.gmail.com> Hi Jon - I have see similar errors like this in the past, but I don't have any in my backgroundrb log now. I didn't specifically track down and fix this error, but I made some other changes that may have inadvertantly avoided this problem. Those changes were: 1.) Avoid using the results feature at all. All status from workers is stored in the db now. 2.) Call self.delete at the end of the worker doing its work 3.) Simplifying the workers themselves. They now just load arguments and call other classes with those arguments. (This step also makes testing easier). I have a scheduled worker that is long running and runs once per minute. That worker looks for pending jobs and spawns new workers to handle those jobs as needed. Those spawner workers take from a few minutes to several hours to do their work before they finish. We have up to 10 workers running at a time. We also have a cron job that checks every minute to see if the scheduled worker has run in the last 3 minutes. If not, it restarts the backgroundrb server and sends a notification email. It's been a little over a week now since the backgroundrb server was auto-restarted. Mason On 2/7/07, Jonathan del Strother wrote: > I'm struggling to keep backgroundrb v2 running for more than 24 > hours. It appears to be running fine for a while, then tries to fire > off a worker (exactly the same worker it's been running for the past > few hours), and it suddenly dies. I haven't found any pattern for the > cause of this. > > In backgroundrb_server.log, the final entry is this : > > 20070206-10:41:45 (5189) Schedule triggered: # 0x2afb643b56c0> job=# backgroundrb/server/lib/backgroundrb/middleman.rb:355>, > trigger=# @end_time=nil, @start_time=Tue Feb 06 03:41:45 -0800 2007>, > earliest=Tue Feb 06 10:41:45 -0800 2007, last=Tue Feb 06 10:41:45 > -0800 2007> > 20070206-10:41:45 (5189) failed to find slave socket - (RuntimeError) > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/slave-1.2.0/lib/ > slave.rb:435:in `initialize' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/middleman.rb:210:in `new' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/middleman.rb:210:in `new_worker' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/thread_pool.rb:36:in `dispatch' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/thread_pool.rb:22:in `initialize' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/thread_pool.rb:22:in `new' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/thread_pool.rb:22:in `dispatch' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/middleman.rb:199:in `new_worker' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/middleman.rb:357:in `schedule_worker' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/scheduler.rb:46:in `call' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/scheduler.rb:46:in `run' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/scheduler.rb:40:in `each' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/scheduler.rb:40:in `run' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/scheduler.rb:35:in `loop' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/scheduler.rb:35:in `run' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/scheduler.rb:95:in `run' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/scheduler.rb:94:in `initialize' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/scheduler.rb:94:in `new' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/scheduler.rb:94:in `run' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb/middleman.rb:106:in `setup' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb_server.rb:306:in `run' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/application.rb:186:in `call' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/application.rb:186:in `start_proc' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/daemonize.rb:192:in `call' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/daemonize.rb:192:in `call_as_daemon' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/application.rb:190:in `start_proc' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/application.rb:226:in `start' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/controller.rb:69:in `run' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons.rb:182:in `run_proc' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/cmdline.rb:94:in `call' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/cmdline.rb:94:in `catch_exceptions' > 20070206-10:41:45 (5189) /usr/lib64/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons.rb:181:in `run_proc' > 20070206-10:41:45 (5189) .../vendor/plugins/backgroundrb/server/lib/ > backgroundrb_server.rb:301:in `run' > 20070206-10:41:45 (5189) .../script/backgroundrb:29 > > > > This happens both on my EngineYard server, and running locally on > intel OS X 10.4.8. > > > Any suggestions? Anyone else experiencing this? > > Jon > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > From jerry at jerryr.com Mon Feb 12 09:59:22 2007 From: jerry at jerryr.com (Jerry Richardson) Date: Mon, 12 Feb 2007 09:59:22 -0500 Subject: [Backgroundrb-devel] -c switch in the startup command Message-ID: <9ca85dfc0702120659j11556a99vd8758b47b45611bd@mail.gmail.com> I have been strugging with getting backgroundrb to stay in the correct environment using multiple configuration files and the -c switch when starting backgroundrb. If I start brb like this: ./script/backgroundrb run RAILS_ENV=development -- -c ../config/development_background.yml where development_background.yml specifies "development" for rails_env and environment, the first worker created does, in fact, use the development environment. But on the second request, the configuration details from backgroundrb.yml are used, causing the worker to be erroneously led to the production database. With Capistrano, I really don't want to have to edit my background.yml on the server, using vi, after each deployment. But so far, I have not been able to come up with a better solution. Has anyone else experienced this? I hope I am just missing something simple. Jerry Richardson jerry at jerryr.com P.S. I have also tried a few other startup commands, with the same problem: ./script/backgroundrb run -- -c ../config/development_background.yml ./script/backgroundrb run RAILS_ENV=development -- -c config/development_background.yml ./script/backgroundrb run RAILS_ENV=development -- -c ~/sites/iblinkink/config/development_background.yml -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070212/b75016e2/attachment.html From ezmobius at gmail.com Mon Feb 12 14:01:31 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Mon, 12 Feb 2007 11:01:31 -0800 Subject: [Backgroundrb-devel] -c switch in the startup command In-Reply-To: <9ca85dfc0702120659j11556a99vd8758b47b45611bd@mail.gmail.com> References: <9ca85dfc0702120659j11556a99vd8758b47b45611bd@mail.gmail.com> Message-ID: <0082BF3F-0994-488E-9538-2B21A335FDC2@brainspl.at> Jerry- Why don't you put your production backgroundrb.yml on yoru server in the shared directory and have it get symlinked in after deploy? This way the production site will always have the right yml file and you can modify it locally to whatever you want and still be sure it gets the correct one on the server. -Ezra On Feb 12, 2007, at 6:59 AM, Jerry Richardson wrote: > I have been strugging with getting backgroundrb to stay in the > correct environment using multiple configuration files and the -c > switch when starting backgroundrb. > > If I start brb like this: > > ./script/backgroundrb run RAILS_ENV=development -- -c ../config/ > development_background.yml > > where development_background.yml specifies "development" for > rails_env and environment, the first worker created does, in fact, > use the development environment. But on the second request, the > configuration details from backgroundrb.yml are used, causing the > worker to be erroneously led to the production database. > > With Capistrano, I really don't want to have to edit my > background.yml on the server, using vi, after each deployment. But > so far, I have not been able to come up with a better solution. > > Has anyone else experienced this? I hope I am just missing > something simple. > > Jerry Richardson > jerry at jerryr.com > > P.S. I have also tried a few other startup commands, with the same > problem: > > ./script/backgroundrb run -- -c ../config/development_background.yml > ./script/backgroundrb run RAILS_ENV=development -- -c config/ > development_background.yml > ./script/backgroundrb run RAILS_ENV=development -- -c ~/sites/ > iblinkink/config/development_background.yml > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From ashwin.bvn at azri.biz Wed Feb 14 02:30:16 2007 From: ashwin.bvn at azri.biz (Ashwin) Date: Wed, 14 Feb 2007 13:00:16 +0530 Subject: [Backgroundrb-devel] Scheduling in backgroundrb not working Message-ID: <45D2BA88.7070205@azri.biz> Hi , How do i schedule a job that can send emails at intervals of time using backgroundrb and rails For testing When i hit the controller i'm able send the emails. but that is not i intend to do ..... I want to use backgroundrb and rails in which i'll schedule a job for every 5 minutes/ 1 minute or so..... to send an email But when i write .yml file as given by the http://backgroundrb.rubyforge.org/ I'm unable to send emails ....... Infact my backgroundrb_server.log shows that scheduler is not even get triggered for every minute or so I've no clue y the Scheduler is not working for every 1 minute or so ........ Any help is appreciated !!!! My Server details: Ruby 1.8.4 Rails 1.1.6 Backgroundrb - 1.2.1 CENT OS .. (Installed backgroundrb as rails plugin ie. /vendor/plugins/background...) ------------------------------------ backgroundrb.yml----------------- :host: localhost :port: 2000 :rails_env: development my_scheduler: :class: :mailman_worker :job_key: :foo_name :worker_method: :send_emails_to_people :trigger_args: 0 */1 * * * * * ------------------------------------------my mailman_worker.rb -------- class MailmanWorker < BackgrounDRb::Worker::RailsBase def do_work(args) # This method is called in it's own new thread when you # call new worker. args is set to :args # Replace this with your code # logger.info('I am in do work') end def send_emails_to_people @d_evals = User.find(:all,:conditions => ['id <= ?',3] for lop in @d_users logger.info('I am in loop') @user = User.find(:first, :conditions => [ 'id = ?',lop.id]) UserNotify.deliver_people_emails(@user) end end end MailmanWorker.register -------------------------------------Controller code----- class TestffController < ApplicationController def a_pop MiddleMan.new_worker(:class => :mailman_worker, :job_key => :foo_name) worker = MiddleMan.worker(:foo_name) worker.send_emails_to_people worker.delete end end --------------------------backgroundrb_server.log--------------------------------------------- I am in do work 20070213-20:15:22 (29661) I am in send_emails_to_people 20070213-20:15:22 (29661) I am in loop 20070213-20:16:04 (29668) Starting WorkerLogger 20070213-20:16:05 (29669) In ResultsWorker 20070213-20:16:07 (29669) I am in do work 20070213-20:16:07 (29669) I am in send_emails_to_evaluators 20070213-20:16:07 (29669) I am in loop 20070213-20:16:13 (29669) I am in loop 20070213-20:16:19 (29669) I am in loop 20070214-13:40:47 (1672) Starting WorkerLogger 20070214-13:40:48 (1673) In ResultsWorker 20070214-13:41:32 (1673) I am in do work 20070214-13:41:32 (1673) I am in send_emails_to_people 20070214-13:41:33 (1673) I am in loop 20070214-13:41:39 (1673) I am in loop 20070214-13:41:46 (1673) I am in loop 0070214-13:45:48 (1694) Starting WorkerLogger 20070214-13:45:49 (1695) In ResultsWorker ------ Ashwin Kumar From masonhale at gmail.com Wed Feb 14 11:07:17 2007 From: masonhale at gmail.com (Mason Hale) Date: Wed, 14 Feb 2007 10:07:17 -0600 Subject: [Backgroundrb-devel] Scheduling in backgroundrb not working In-Reply-To: <45D2BA88.7070205@azri.biz> References: <45D2BA88.7070205@azri.biz> Message-ID: <8bca3aa10702140807g164e452cy2f51cbdd250a6adc@mail.gmail.com> Ashwin -- The schedules go in a separate file, /config/backgroundrb_schedules.yml, not in the main backgroundrb.yml file. Just copy the schedule block from your backgroundrb.yml file to a new backgroundrb_schedules.yml file, restart backgroundrb, and it should work. Mason On 2/14/07, Ashwin wrote: > Hi , > How do i schedule a job that can send emails at intervals of time > using backgroundrb and rails > > For testing When i hit the controller i'm able send the emails. > but that is not i intend to do ..... > > I want to use backgroundrb and rails in which i'll schedule a job > for every 5 minutes/ 1 minute or so..... to send an email > > But when i write .yml file as given by the > http://backgroundrb.rubyforge.org/ > > I'm unable to send emails ....... Infact my backgroundrb_server.log > shows that scheduler is not even get triggered for every minute or > so > > I've no clue y the Scheduler is not working for every 1 minute or > so > ........ Any help is appreciated !!!! > > > > My Server details: > > Ruby 1.8.4 > Rails 1.1.6 > Backgroundrb - 1.2.1 > CENT OS .. > (Installed backgroundrb as rails plugin ie. /vendor/plugins/background...) > > > ------------------------------------ backgroundrb.yml----------------- > > :host: localhost > :port: 2000 > :rails_env: development > > > my_scheduler: > :class: :mailman_worker > :job_key: :foo_name > :worker_method: :send_emails_to_people > :trigger_args: 0 */1 * * * * * > > > > ------------------------------------------my mailman_worker.rb -------- > > class MailmanWorker < BackgrounDRb::Worker::RailsBase > > def do_work(args) > # This method is called in it's own new thread when you > # call new worker. args is set to :args > # Replace this with your code > # > logger.info('I am in do work') > end > > def send_emails_to_people > > @d_evals = User.find(:all,:conditions => ['id <= ?',3] > > for lop in @d_users > logger.info('I am in loop') > @user = User.find(:first, :conditions => [ 'id = ?',lop.id]) > UserNotify.deliver_people_emails(@user) > end > > end > > end > MailmanWorker.register > > > -------------------------------------Controller code----- > > class TestffController < ApplicationController > > > def a_pop > MiddleMan.new_worker(:class => :mailman_worker, :job_key => > :foo_name) > worker = MiddleMan.worker(:foo_name) > worker.send_emails_to_people > worker.delete > end > > end > > > --------------------------backgroundrb_server.log--------------------------------------------- > > I am in do work > 20070213-20:15:22 (29661) I am in send_emails_to_people > 20070213-20:15:22 (29661) I am in loop > 20070213-20:16:04 (29668) Starting WorkerLogger > 20070213-20:16:05 (29669) In ResultsWorker > 20070213-20:16:07 (29669) I am in do work > 20070213-20:16:07 (29669) I am in send_emails_to_evaluators > 20070213-20:16:07 (29669) I am in loop > 20070213-20:16:13 (29669) I am in loop > 20070213-20:16:19 (29669) I am in loop > > 20070214-13:40:47 (1672) Starting WorkerLogger > 20070214-13:40:48 (1673) In ResultsWorker > 20070214-13:41:32 (1673) I am in do work > 20070214-13:41:32 (1673) I am in send_emails_to_people > 20070214-13:41:33 (1673) I am in loop > 20070214-13:41:39 (1673) I am in loop > 20070214-13:41:46 (1673) I am in loop > > > 0070214-13:45:48 (1694) Starting WorkerLogger > 20070214-13:45:49 (1695) In ResultsWorker > > > > ------ Ashwin Kumar > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > From ivorpaul at gmail.com Wed Feb 14 11:06:12 2007 From: ivorpaul at gmail.com (Ivor Paul) Date: Wed, 14 Feb 2007 18:06:12 +0200 Subject: [Backgroundrb-devel] cron like behaviour? Message-ID: 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 move some of the files into different directory structures/create symlinks from different locations. What bugs me is how I get a worker to do_some_work without a user event. I will greatly appreciate some pointers. Thanks a lot. Ivor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070214/db8e543f/attachment.html From masonhale at gmail.com Wed Feb 14 11:34:18 2007 From: masonhale at gmail.com (Mason Hale) Date: Wed, 14 Feb 2007 10:34:18 -0600 Subject: [Backgroundrb-devel] cron like behaviour? In-Reply-To: References: Message-ID: <8bca3aa10702140834k280588acwc37539841b2d1af7@mail.gmail.com> Ivor - Sounds like BackgroundRb is a good solution for your problem. You define scheduled jobs in a file /config/backgroundrb_schedules.yml -- these will get fired off on the interval you set. Here's what my backgroundrb_schedules.yml looks like: scheduled_publisher: :class: :scheduled_publish_worker :job_key: :scheduled_publisher :worker_method: :do_publish :worker_method_args: scheduled workers require some args, so here you go... :trigger_args: :start: <%= Time.now + 5.seconds %> :repeat_interval: <%= 1.minutes %> This kicks off a worker that checks for pending publications every minute. Note the :worker_method_args -- field. I found that if you do not provide a value for this field your scheduled worked won't run. My scheduled_publish_worker doesn't need any args -- so I provided a placeholder value for :worker_method_args. Mason On 2/14/07, Ivor Paul wrote: > 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 move some of the files into different directory structures/create > symlinks from different locations. > > What bugs me is how I get a worker to do_some_work without a user event. > > I will greatly appreciate some pointers. > > Thanks a lot. > Ivor > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > From bill.walton at charter.net Wed Feb 14 16:51:09 2007 From: bill.walton at charter.net (Bill Walton) Date: Wed, 14 Feb 2007 15:51:09 -0600 Subject: [Backgroundrb-devel] [Slightly OT] Timing out during File Save Message-ID: <00f501c75082$3cfa0fa0$6401a8c0@Presario> Apologies in advance for the slightly OT post, and for the cross-post, but I thought you folks would probably have more experience with this 'problem' given your use of BackgroundRb. A little background (no pun intended ;-) ) I'm using BackgroundRb for session management. After a set period of user inactivity I kill their session and all the information they've entered and files created from that info is deleted. I know it's a bit unusual but it's warrented in this app. BackgroundRb was the tool I needed because I need to display a count-down timer in their browser. It is working beautifully. The 'problem' I'm trying to solve is that the 'Save File' dialog box is modal so it prevents the timer in the browser from getting updated. The file download to the client has finished, so the timer on the server is reset and BackgroundRb starts counting down again. But the visitor has no way of knowing that. It looks to them like the timer has stopped but, in fact, the count down has restarted and is underway. Their session may time out and data get deleted before they finish the File Save on their PC. At that point they're left looking at a browser that still says they have time left but that's, in fact, completely done and unresponsive. Ideally, I'd like not to restart the timer until I know they've finished the 'Save File' on the client. Anybody have any ideas on how to do this? Or any other ideas on how I might handle it other than just warning them before they start the 'Save'? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070214/0bf5c64f/attachment.html From blucasco at gmail.com Thu Feb 15 16:49:24 2007 From: blucasco at gmail.com (Brian Lucas) Date: Thu, 15 Feb 2007 14:49:24 -0700 Subject: [Backgroundrb-devel] new syntax for autostart and repeat Message-ID: <45d4d574.0a59553b.1687.550f@mx.google.com> Hello: I'm a little confused as to the >0.20 brb syntax as it relates to autostart and repeat. In short, I'd like to know the easiest way to automatically start a worker and have it repeat every xx minutes. This was easy in the previous version because you would simply do : 'repeat.every 20.minutes' or similar in the worker. I'm sure it's easy, but I'm not sure how to place something in backgroundrb_schedules.yml to get it to autostart. Any easy tips? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070215/cc3438be/attachment.html From blucasco at gmail.com Thu Feb 15 17:50:56 2007 From: blucasco at gmail.com (Brian Lucas) Date: Thu, 15 Feb 2007 15:50:56 -0700 Subject: [Backgroundrb-devel] disregard RE: new syntax for autostart and repeat Message-ID: <45d4e3db.6361d231.7a4c.ffffee90@mx.google.com> So disregard this question. I followed Mason Hale's suggestion that I pass in some worker_args and all is well in the scheduler.yml file. Brian _____ From: Brian Lucas [mailto:blucasCO at gmail.com] Sent: Thursday, February 15, 2007 2:49 PM To: 'backgroundrb-devel at rubyforge.org' Subject: new syntax for autostart and repeat Hello: I'm a little confused as to the >0.20 brb syntax as it relates to autostart and repeat. In short, I'd like to know the easiest way to automatically start a worker and have it repeat every xx minutes. This was easy in the previous version because you would simply do : 'repeat.every 20.minutes' or similar in the worker. I'm sure it's easy, but I'm not sure how to place something in backgroundrb_schedules.yml to get it to autostart. Any easy tips? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070215/9ae5f2fc/attachment.html From Marc at SoftwareHackery.Com Fri Feb 16 11:15:05 2007 From: Marc at SoftwareHackery.Com (Marc Evans) Date: Fri, 16 Feb 2007 11:15:05 -0500 (EST) Subject: [Backgroundrb-devel] Starting / stopping background rb when apache starts/stops Message-ID: <20070216110859.E54198@me.softwarehackery.com> Hello - I would like to figure out a way to have backgroundrb start/stop with the same UID that dispatch.fcgi uses, at the same point in time that apache is started/stopped. I see a technique that seems plausable in this archive message: http://rubyforge.org/pipermail/backgroundrb-devel/2007-February/000723.html which addresses the starting aspect, in a lazy fashion. That seems fine, particularly given it's resilience to unexpected terminations of the backgroundrb processes. What I have not seen any discussion of is how to insure that backgroundrb is terminated (ideally cleanly) at the point in time that apache (or whatever web server you use) is terminated. In other words, I am hoping to use "apachectl {start|stop}" to control dispatch.fcgi and backgroundrb. Does anyone have any suggestions? Thanks in advance - Marc From phlip2005 at gmail.com Sun Feb 18 17:22:34 2007 From: phlip2005 at gmail.com (Phlip) Date: Sun, 18 Feb 2007 14:22:34 -0800 Subject: [Backgroundrb-devel] unit tests vs database state Message-ID: <056001c753ab$4a6fea70$6601a8c0@Marley> BackgrounDRb-ers: I have this friend who claims that everything should have a unit test. We want to use BackgrounDRb in a test-first setting. When I update a database, to get it ready for testing, the update happens inside the MySQL transaction of the test process. The worker then runs in another process and sees the database's original state. Turning off the transactions, in test_helper.rb, doesn't fix this effect. I discovered that effect on one project, and worked around it. Now I will try to write unit tests for another project, and I will report back here if the effect gets better, or worse. I'm just asking in advance, to see if anyone has discovered this problem, and how to fix it... -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!! From blucasco at gmail.com Sun Feb 18 18:50:26 2007 From: blucasco at gmail.com (Brian Lucas) Date: Sun, 18 Feb 2007 16:50:26 -0700 Subject: [Backgroundrb-devel] backgroundrb launches concurrent instances of same job Message-ID: <45d8e64a.3bdb3a29.7a4c.ffffc0aa@mx.google.com> 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... :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 appreciated! Brian From skaar at waste.org Sun Feb 18 20:35:40 2007 From: skaar at waste.org (skaar) Date: Sun, 18 Feb 2007 19:35:40 -0600 Subject: [Backgroundrb-devel] backgroundrb launches concurrent instances of same job In-Reply-To: <45d8e64a.3bdb3a29.7a4c.ffffc0aa@mx.google.com> References: <45d8e64a.3bdb3a29.7a4c.ffffc0aa@mx.google.com> Message-ID: <20070219013540.GA22601@waste.org> * Brian Lucas (blucasco at gmail.com) [070218 17:48]: > 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... > :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. you see these as processes or as log entries? /skaar -- ---------------------------------------------------------------------- |\|\ where in the | s_u_b_s_t_r_u_c_t_i_o_n | | >=========== W.A.S.T.E. | genarratologies |/|/ (_) is the wisdom | skaar at waste.org ---------------------------------------------------------------------- From blucasco at gmail.com Mon Feb 19 11:26:45 2007 From: blucasco at gmail.com (Brian Lucas) Date: Mon, 19 Feb 2007 09:26:45 -0700 Subject: [Backgroundrb-devel] backgroundrb launches concurrent instances of same job In-Reply-To: <20070219013540.GA22601@waste.org> Message-ID: <45d9cfcf.41aba8f1.7a89.ffffa4ad@mx.google.com> A logger entry lets me know what action is being performed by the job. The job iterates through a loop and I see two different "loops" that being worked on simultaneously. The loop is a simple ruby loop: category=Category.find(...) Locations.each { |location| logger.info('Category:'+category+' CityUpdater: starting city '+city) ...do work here... } It's strange that it's launching two instances. -----Original Message----- From: skaar [mailto:skaar at waste.org] Sent: Sunday, February 18, 2007 6:36 PM To: Brian Lucas Cc: backgroundrb-devel at rubyforge.org Subject: Re: [Backgroundrb-devel] backgroundrb launches concurrent instances of same job * Brian Lucas (blucasco at gmail.com) [070218 17:48]: > 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... > :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. you see these as processes or as log entries? /skaar -- ---------------------------------------------------------------------- |\|\ where in the | s_u_b_s_t_r_u_c_t_i_o_n | | >=========== W.A.S.T.E. | genarratologies |/|/ (_) is the wisdom | skaar at waste.org ---------------------------------------------------------------------- From dburkes at infoteria.com Mon Feb 19 11:44:16 2007 From: dburkes at infoteria.com (Daniel Burkes) Date: Mon, 19 Feb 2007 08:44:16 -0800 Subject: [Backgroundrb-devel] Hello world Message-ID: <81A9B494-AD02-4565-B9F2-1AA8229F82B8@infoteria.com> Hi- Danny Burkes here from Lingr (http://www.lingr.com). We're evaluating bdrb and so far, so good. It's deployed in staging now and seems to be working fine. I have a couple of questions that I couldn't find references to in the archive, so here it goes- 1. Is there any way to do a "graceful" stop of bdrb? What I mean is, I want to stop bdrb, but I want it to wait for all workers to finish (both the ones that are currently running in the pool, plus the ones that are queued). That is, during the graceful shutdown period, bdrb should not accept any new workers, but it should complete all the currently-running and queued workers. 2. We use nagios for monitoring- has anyone whipped up a check_bdrb task for nagios? Thanks and we're looking forward to joining the bdrb satisfied-user community :-) Best Regards, Danny Burkes From caifara.subscribe at gmail.com Tue Feb 20 10:49:25 2007 From: caifara.subscribe at gmail.com (Ivo Dancet) Date: Tue, 20 Feb 2007 16:49:25 +0100 Subject: [Backgroundrb-devel] rails 1.2.1, locomotive and backgroundrb Message-ID: <5B4EE359-C92D-404B-9403-59F17B643150@gmail.com> Hi I just tried to move my project to rails 1.2.1 on my locomotive development setup. It seems that backgroundrb is not willing to start up anymore. If I switch locomotive back to 1.1.6, everthing is fine. This is the error I get while attempting to start backgroundrb: /Applications/Locomotive2/Bundles/standardRailsJan2007.locobundle/ powerpc/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- slave (LoadError) from /Applications/Locomotive2/Bundles/ standardRailsJan2007.locobundle/powerpc/lib/ruby/site_ruby/1.8/ rubygems/custom_require.rb:27:in `require' from /Users/caifara/Desktop/trunk/vendor/plugins/ backgroundrb/server/lib/backgroundrb/middleman.rb:12 from /Applications/Locomotive2/Bundles/ standardRailsJan2007.locobundle/powerpc/lib/ruby/site_ruby/1.8/ rubygems/custom_require.rb:27:in `gem_original_require' from /Applications/Locomotive2/Bundles/ standardRailsJan2007.locobundle/powerpc/lib/ruby/site_ruby/1.8/ rubygems/custom_require.rb:27:in `require' from /Users/caifara/Desktop/trunk/vendor/plugins/ backgroundrb/server/lib/backgroundrb_server.rb:4 from script/backgroundrb:27:in `require' from script/backgroundrb:27 From skaar at waste.org Tue Feb 20 10:58:52 2007 From: skaar at waste.org (skaar) Date: Tue, 20 Feb 2007 09:58:52 -0600 Subject: [Backgroundrb-devel] rails 1.2.1, locomotive and backgroundrb In-Reply-To: <5B4EE359-C92D-404B-9403-59F17B643150@gmail.com> References: <5B4EE359-C92D-404B-9403-59F17B643150@gmail.com> Message-ID: <20070220155852.GA25535@waste.org> * Ivo Dancet (caifara.subscribe at gmail.com) [070220 09:56]: > Hi > > I just tried to move my project to rails 1.2.1 on my locomotive > development setup. It seems that backgroundrb is not willing to start > up anymore. If I switch locomotive back to 1.1.6, everthing is fine. > > This is the error I get while attempting to start backgroundrb: > > /Applications/Locomotive2/Bundles/standardRailsJan2007.locobundle/ > powerpc/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require': no such file to load -- slave (LoadError) > from /Applications/Locomotive2/Bundles/ seems like it can't find the slave library /skaar -- ---------------------------------------------------------------------- |\|\ where in the | s_u_b_s_t_r_u_c_t_i_o_n | | >=========== W.A.S.T.E. | genarratologies |/|/ (_) is the wisdom | skaar at waste.org ---------------------------------------------------------------------- From caifara.subscribe at gmail.com Tue Feb 20 11:29:10 2007 From: caifara.subscribe at gmail.com (Ivo Dancet) Date: Tue, 20 Feb 2007 17:29:10 +0100 Subject: [Backgroundrb-devel] rails 1.2.1, locomotive and backgroundrb In-Reply-To: <20070220155852.GA25535@waste.org> References: <5B4EE359-C92D-404B-9403-59F17B643150@gmail.com> <20070220155852.GA25535@waste.org> Message-ID: Well, that was a fast and accurate reply... Thanks! (can't believe I didn't came up with that straight-forward answer) Op 20-feb-07, om 16:58 heeft skaar het volgende geschreven: > * Ivo Dancet (caifara.subscribe at gmail.com) [070220 09:56]: >> Hi >> >> I just tried to move my project to rails 1.2.1 on my locomotive >> development setup. It seems that backgroundrb is not willing to start >> up anymore. If I switch locomotive back to 1.1.6, everthing is fine. >> >> This is the error I get while attempting to start backgroundrb: >> >> /Applications/Locomotive2/Bundles/standardRailsJan2007.locobundle/ >> powerpc/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in >> `gem_original_require': no such file to load -- slave (LoadError) >> from /Applications/Locomotive2/Bundles/ > > seems like it can't find the slave library > > /skaar > > > -- > ---------------------------------------------------------------------- > |\|\ where in the | s_u_b_s_t_r_u_c_t_i_o_n > | | >=========== W.A.S.T.E. | genarratologies > |/|/ (_) is the wisdom | skaar at waste.org > ---------------------------------------------------------------------- From steviec at gmail.com Tue Feb 20 14:51:15 2007 From: steviec at gmail.com (Stevie Clifton) Date: Tue, 20 Feb 2007 14:51:15 -0500 Subject: [Backgroundrb-devel] "Text is not a module" Message-ID: <2caed6660702201151p1b21bdb6v956c892eda5578d8@mail.gmail.com> Hello all, After upgrading to Rails 1.2.2, I'm getting a strange error when one of my workers is invoked. The worker is responsible for monitoring a folder (using directory_watcher) and emailing a specific user when a file is dropped there, but it's bombing immediately upon instantiation (or maybe when trying to instantiate ActionMailer?) with the error "Text is not a Module". Thanks for any input on this one! stevie 20070220-14:41:56 (4800) Text is not a module - (TypeError) 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/actionmailer/lib/action_mailer/vendor/text/format.rb:49 20070220-14:41:56 (4800) /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/actionmailer/lib/action_mailer/mail_helper.rb:1 20070220-14:41:56 (4800) /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/actionmailer/lib/action_mailer.rb:38 20070220-14:41:56 (4800) /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/railties/lib/initializer.rb:162:in `require_frameworks' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/railties/lib/initializer.rb:162:in `require_frameworks' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/railties/lib/initializer.rb:83:in `process' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/railties/lib/initializer.rb:43:in `run' 20070220-14:41:56 (4800) /u/testapp/config/environment.rb:14 20070220-14:41:56 (4800) /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker_rails.rb:24:in `initialize' 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in `new_worker' 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch' 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `dispatch' 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in `new_worker' 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform' 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run' 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:315:in `run' 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:186:in `start_proc' 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/daemonize.rb:192:in `call_as_daemon' 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:190:in `start_proc' 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:226:in `start' 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/controller.rb:69:in `run' 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons.rb:182:in `run_proc' 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/cmdline.rb:94:in `catch_exceptions' 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons.rb:181:in `run_proc' 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in `run' 20070220-14:41:56 (4800) script/backgroundrb:30 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070220/7753ad5f/attachment-0001.html From bill.walton at charter.net Tue Feb 20 15:48:27 2007 From: bill.walton at charter.net (Bill Walton) Date: Tue, 20 Feb 2007 14:48:27 -0600 Subject: [Backgroundrb-devel] error message for record not found ? Message-ID: <023901c75530$86987cc0$6401a8c0@Presario> I'm using backgroundrb for session management and deletion of visitor-entered information when a session is abandoned. The visitor can either click a button to end their session and remove their data, or backgroundrb will do it for them after 5 minutes of inactivity. Everything's working fine, I think. If the visitor explicitly logs out, then when the worker checks for their record it won't be there which will trigger logic that says 'you're done. close the connection and kill yourself'. What makes me a little worried is that I'm getting what looks like an error message in backgroundrb.log. I've included it below. I've also included the worker code. Can anybody tell me how to verify that the worker is actually closing the connection and then creating suicide? Versus dying because of this failed find and not closing the connection correctly? Thanks, Bill ----------- log message ----------- Couldn't find Emrec with ID=1 - (ActiveRecord::RecordNotFound) C:/InstantRails-1.3/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/base.rb:955:in `find_one' C:/InstantRails-1.3/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/base.rb:941:in `find_from_ids' C:/InstantRails-1.3/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/base.rb:382:in `find' ./script/backgroundrb/../../config/../lib/workers/session_worker.rb:20:in `watch_session' ./script/backgroundrb/../../config/../lib/workers/session_worker.rb:12:in `do_work' ./script/backgroundrb/../../config/../vendor/plugins/backgroundrb/backgroundrb_rails.rb:36:in `start_process' ./script/backgroundrb/../../config/../vendor/plugins/backgroundrb/backgroundrb_rails.rb:32:in `start_process' ./script/backgroundrb/../../config/../vendor/plugins/backgroundrb/backgroundrb.rb:57:in `new_worker' C:/InstantRails-1.3/ruby/lib/ruby/1.8/thread.rb:135:in `synchronize' ./script/backgroundrb/../../config/../vendor/plugins/backgroundrb/backgroundrb.rb:49:in `new_worker' C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1512:in `perform' C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1427:in `run' C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1424:in `run' C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' script/backgroundrb/start:108 ------------ Worker code ---------- class SessionWorker < BackgrounDRb::Rails attr_reader :time_remaining def do_work(args) @time_remaining = args[:initial_setting].to_i @emrec_id = args[:emrec_id] @session_id = args[:session_id] @session_rec = Session.find(:first, :conditions => ["sessid = ?", @session_id]) watch_session(args) sleep(2) clean_up end def watch_session(args) while @time_remaining > 0 sleep(1) emrec = Emrec.find(@emrec_id) if emrec != nil if emrec.timer_suspended == 'no' last_activity = emrec.last_updated_at time_remaining_float = (last_activity + args[:initial_setting].to_i) - Time.now @time_remaining = time_remaining_float.to_i end else @time_remaining = 0 end end end def clean_up emrec = Emrec.find(@emrec_id) if emrec != nil emrec.cleanup Session.delete(@session_rec.id) end ActiveRecord::Base.connection.disconnect! ::BackgrounDRb::MiddleMan.instance.delete_worker @_job_key end end -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070220/abf58a04/attachment.html From maillist at steelskies.com Tue Feb 20 15:39:32 2007 From: maillist at steelskies.com (Jonathan del Strother) Date: Tue, 20 Feb 2007 20:39:32 +0000 Subject: [Backgroundrb-devel] "Text is not a module" In-Reply-To: <2caed6660702201151p1b21bdb6v956c892eda5578d8@mail.gmail.com> References: <2caed6660702201151p1b21bdb6v956c892eda5578d8@mail.gmail.com> Message-ID: <5ADD2FE8-8708-4C61-ABA5-937ACDB3AC3D@steelskies.com> Looks like something else has defined Text before ActionMailer. Try a breakpoint in format.rb:48 and see what Text is. I'm guessing your worker is requiring a library that's defined Text as a class or something. Jon On 20 Feb 2007, at 19:51, Stevie Clifton wrote: > Hello all, > > After upgrading to Rails 1.2.2, I'm getting a strange error when > one of my workers is invoked. The worker is responsible for > monitoring a folder (using directory_watcher) and emailing a > specific user when a file is dropped there, but it's bombing > immediately upon instantiation (or maybe when trying to instantiate > ActionMailer?) with the error "Text is not a Module". > > Thanks for any input on this one! > > stevie > > 20070220-14:41:56 (4800) Text is not a module - (TypeError) > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > actionmailer/lib/action_mailer/vendor/text/format.rb:49 > > 20070220-14:41:56 (4800) /usr/local/lib/site_ruby/1.8/rubygems/ > custom_require.rb:27:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:495:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:342:in `new_constants_in' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:495:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > actionmailer/lib/action_mailer/mail_helper.rb:1 > > 20070220-14:41:56 (4800) /usr/local/lib/site_ruby/1.8/rubygems/ > custom_require.rb:27:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:495:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:342:in `new_constants_in' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:495:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > actionmailer/lib/action_mailer.rb:38 > > 20070220-14:41:56 (4800) /usr/local/lib/site_ruby/1.8/rubygems/ > custom_require.rb:27:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:495:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:342:in `new_constants_in' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:495:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/railties/ > lib/initializer.rb:162:in `require_frameworks' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/railties/ > lib/initializer.rb:162:in `require_frameworks' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/railties/ > lib/initializer.rb:83:in `process' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/railties/ > lib/initializer.rb:43:in `run' > > 20070220-14:41:56 (4800) /u/testapp/config/environment.rb:14 > > 20070220-14:41:56 (4800) /usr/local/lib/site_ruby/1.8/rubygems/ > custom_require.rb:27:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:495:in `require' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:342:in `new_constants_in' > > 20070220-14:41:56 (4800) /u/testapp/config/../vendor/rails/ > activerecord/lib/../../activesupport/lib/active_support/ > dependencies.rb:495:in `require' > > 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/ > server/lib/backgroundrb/worker_rails.rb:24:in `initialize' > > 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/ > server/lib/backgroundrb/middleman.rb:211:in `new_worker' > > 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/ > server/lib/backgroundrb/thread_pool.rb:36:in `dispatch' > > 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/ > server/lib/backgroundrb/thread_pool.rb:22:in `dispatch' > > 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/ > server/lib/backgroundrb/middleman.rb:199:in `new_worker' > > 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1552:in > `perform_without_block' > > 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1512:in > `perform' > > 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1586:in > `main_loop' > > 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1582:in > `main_loop' > > 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1578:in > `main_loop' > > 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' > > 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run' > > 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1344:in > `initialize' > > 20070220-14:41:56 (4800) /usr/lib/ruby/1.8/drb/drb.rb:1624:in > `start_service' > > 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/ > server/lib/backgroundrb_server.rb:315:in `run' > > 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/application.rb:186:in `start_proc' > > 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/daemonize.rb:192:in `call_as_daemon' > > 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/application.rb:190:in `start_proc' > > 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/application.rb:226:in `start' > > 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/controller.rb:69:in `run' > > 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons.rb:182:in `run_proc' > > 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons/cmdline.rb:94:in `catch_exceptions' > > 20070220-14:41:56 (4800) /usr/lib/ruby/gems/1.8/gems/daemons-1.0.4/ > lib/daemons.rb:181:in `run_proc' > > 20070220-14:41:56 (4800) /u/testapp/vendor/plugins/backgroundrb/ > server/lib/backgroundrb_server.rb:301:in `run' > > 20070220-14:41:56 (4800) script/backgroundrb:30 > > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From ezmobius at gmail.com Tue Feb 20 16:43:57 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Tue, 20 Feb 2007 13:43:57 -0800 Subject: [Backgroundrb-devel] error message for record not found ? In-Reply-To: <023901c75530$86987cc0$6401a8c0@Presario> References: <023901c75530$86987cc0$6401a8c0@Presario> Message-ID: Bill- It looks like a standard record not found error. You should probably wrap your worker codes in begin .. rescue .. end block so you can catch that exception. -Ezra On Feb 20, 2007, at 12:48 PM, Bill Walton wrote: > I'm using backgroundrb for session management and deletion of > visitor-entered information when a session is abandoned. The > visitor can either click a button to end their session and remove > their data, or backgroundrb will do it for them after 5 minutes of > inactivity. > > Everything's working fine, I think. If the visitor explicitly logs > out, then when the worker checks for their record it won't be there > which will trigger logic that says 'you're done. close the > connection and kill yourself'. What makes me a little worried is > that I'm getting what looks like an error message in > backgroundrb.log. I've included it below. I've also included the > worker code. > > Can anybody tell me how to verify that the worker is actually > closing the connection and then creating suicide? Versus dying > because of this failed find and not closing the connection correctly? > > Thanks, > Bill > > ----------- log message ----------- > Couldn't find Emrec with ID=1 - (ActiveRecord::RecordNotFound) > C:/InstantRails-1.3/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.2/ > lib/active_record/base.rb:955:in `find_one' > C:/InstantRails-1.3/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.2/ > lib/active_record/base.rb:941:in `find_from_ids' > C:/InstantRails-1.3/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.2/ > lib/active_record/base.rb:382:in `find' > ./script/backgroundrb/../../config/../lib/workers/session_worker.rb: > 20:in `watch_session' > ./script/backgroundrb/../../config/../lib/workers/session_worker.rb: > 12:in `do_work' > ./script/backgroundrb/../../config/../vendor/plugins/backgroundrb/ > backgroundrb_rails.rb:36:in `start_process' > ./script/backgroundrb/../../config/../vendor/plugins/backgroundrb/ > backgroundrb_rails.rb:32:in `start_process' > ./script/backgroundrb/../../config/../vendor/plugins/backgroundrb/ > backgroundrb.rb:57:in `new_worker' > C:/InstantRails-1.3/ruby/lib/ruby/1.8/thread.rb:135:in `synchronize' > ./script/backgroundrb/../../config/../vendor/plugins/backgroundrb/ > backgroundrb.rb:49:in `new_worker' > C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1552:in > `perform_without_block' > C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1512:in `perform' > C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' > C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' > C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' > C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1427:in `run' > C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1424:in `run' > C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' > C:/InstantRails-1.3/ruby/lib/ruby/1.8/drb/drb.rb:1624:in > `start_service' > script/backgroundrb/start:108 > > > ------------ Worker code ---------- > class SessionWorker < BackgrounDRb::Rails > > attr_reader :time_remaining > > def do_work(args) > @time_remaining = args[:initial_setting].to_i > @emrec_id = args[:emrec_id] > @session_id = args[:session_id] > @session_rec = Session.find(:first, > :conditions => ["sessid = ?", @session_id]) > watch_session(args) > sleep(2) > clean_up > end > > def watch_session(args) > while @time_remaining > 0 > sleep(1) > emrec = Emrec.find(@emrec_id) > if emrec != nil > if emrec.timer_suspended == 'no' > last_activity = emrec.last_updated_at > time_remaining_float = (last_activity + args > [:initial_setting].to_i) - Time.now > @time_remaining = time_remaining_float.to_i > end > else > @time_remaining = 0 > end > end > end > > def clean_up > emrec = Emrec.find(@emrec_id) > if emrec != nil > emrec.cleanup > Session.delete(@session_rec.id) > end > ActiveRecord::Base.connection.disconnect! > ::BackgrounDRb::MiddleMan.instance.delete_worker @_job_key > end > > end > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From dgreig at magian.com Wed Feb 21 17:10:08 2007 From: dgreig at magian.com (Daniel Greig) Date: Thu, 22 Feb 2007 09:10:08 +1100 Subject: [Backgroundrb-devel] accessing controller methods from backgreoundrb Message-ID: <45DCC340.4000504@magian.com> Hi all, I am trying to use backgroundrb to cache a set of controller actions that are quite processor expensive (there is some pretty heavy xml processing going on). In my rails app I have page caching set up to observe the appropriate controllers and models and all works well. However when model changes occur in a backgroundrb process the cache sweeper isn't notified of the changes (and consequently the cache isn't updated). I assume this is because backgroundrb doesn't have access to the controller and view layers? Is it possible to trigger the normal rails cache sweepers from backgroundrb somehow, or, is it possible to gain access to controller methods so that I can use render_to_string and save the output of that action to a file and create the cached files manually? Either option should get me back on track. A final note - the rails application I'm working on needs to be hosted on a windows machine, so I'm stuck using the earlier version of backgroundrb for the time being. thanks, Dan From bernesco at muteki.it Thu Feb 22 09:29:39 2007 From: bernesco at muteki.it (=?ISO-8859-1?Q?Alessio_Bernesco_L=E0vore?=) Date: Thu, 22 Feb 2007 15:29:39 +0100 Subject: [Backgroundrb-devel] failed to find slave socket - (RuntimeError) Message-ID: <2BD388F4-D5CB-4663-8CC1-B40EE303A08A@muteki.it> 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 something like: class ResearchesWorker < BackgrounDRb::Worker::RailsBase def do_work(args) completed = RunningResearch.find(:all,:conditions => ["endtime < ?",Time.now]) for complete in completed complete.complete end self.delete end end ResearchesWorker.register After 4 or 5 minutes of working, the worker stops to respond and i've this error in the log file: 20070222-15:13:37 (15574) failed to find slave socket - (RuntimeError) 20070222-15:13:37 (15574) /usr/local/lib/ruby/gems/1.8/gems/ slave-1.2.0/lib/slave.rb:435:in `initialize' 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb: 210:in `new' 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb: 210:in `new_worker' 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb: 36:in `dispatch' 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb: 22:in `initialize' 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb: 22:in `new' 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb: 22:in `dispatch' 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb: 199:in `new_worker' I've try to keep the workers class as simple and light as i can... any advice about? Thanks, ale. From dburkes at infoteria.com Thu Feb 22 13:31:02 2007 From: dburkes at infoteria.com (Daniel Burkes) Date: Thu, 22 Feb 2007 10:31:02 -0800 Subject: [Backgroundrb-devel] Log rotation Message-ID: <6AE316B1-70F4-48E1-9D32-7E70CE3B7EC6@infoteria.com> What are people doing about rotating backgroundrb.log and backgroundrb_server.log? It looks like the Logger creation is hardcoded in worker.rb and backgroundrb_server.rb, so there's no opportunity to pass my own rotation arguments to Logger.new. Best Regards, Danny From ezmobius at gmail.com Thu Feb 22 13:57:49 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Thu, 22 Feb 2007 10:57:49 -0800 Subject: [Backgroundrb-devel] failed to find slave socket - (RuntimeError) In-Reply-To: <2BD388F4-D5CB-4663-8CC1-B40EE303A08A@muteki.it> References: <2BD388F4-D5CB-4663-8CC1-B40EE303A08A@muteki.it> Message-ID: Hi- You are trying to spawn new workers too fast for the new architecture in bdrb. With a job like this that you want to run every 5 seconds you are way better of creating a single worker that lives forever and just does a loop and sleep then does the work you want. Trying to spawn new workers every 5 seconds will work with the old version of the plugin but not with the new version. Try something more like this: class ResearchesWorker < BackgrounDRb::Worker::RailsBase def do_work(args) loop { completed = RunningResearch.find(:all,:conditions => ["endtime < ?",Time.now]) for complete in completed complete.complete end sleep 5 } end end ResearchesWorker.register Then just have this worker get started at server boot time or whatever and run forever. -Ezra On Feb 22, 2007, at 6:29 AM, Alessio Bernesco L?vore wrote: > 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 something like: > > class ResearchesWorker < BackgrounDRb::Worker::RailsBase > def do_work(args) > completed = RunningResearch.find(:all,:conditions => ["endtime > < ?",Time.now]) > for complete in completed > complete.complete > end > self.delete > end > end > ResearchesWorker.register > > After 4 or 5 minutes of working, the worker stops to respond and i've > this error in the log file: > > 20070222-15:13:37 (15574) failed to find slave socket - (RuntimeError) > 20070222-15:13:37 (15574) /usr/local/lib/ruby/gems/1.8/gems/ > slave-1.2.0/lib/slave.rb:435:in `initialize' > 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ > vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb: > 210:in `new' > 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ > vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb: > 210:in `new_worker' > 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ > vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb: > 36:in `dispatch' > 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ > vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb: > 22:in `initialize' > 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ > vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb: > 22:in `new' > 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ > vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb: > 22:in `dispatch' > 20070222-15:13:37 (15574) /Users/abernesco/Documents/ruby/alfaomega/ > vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb: > 199:in `new_worker' > > > I've try to keep the workers class as simple and light as i can... > any advice about? > > Thanks, > ale. > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From Marc at SoftwareHackery.Com Fri Feb 23 12:49:25 2007 From: Marc at SoftwareHackery.Com (Marc Evans) Date: Fri, 23 Feb 2007 12:49:25 -0500 (EST) Subject: [Backgroundrb-devel] Starting / stopping background rb when apache starts/stops In-Reply-To: <20070216110859.E54198@me.softwarehackery.com> References: <20070216110859.E54198@me.softwarehackery.com> Message-ID: <20070223124155.S12311@me.softwarehackery.com> On Fri, 16 Feb 2007, Marc Evans wrote: > Hello - > > I would like to figure out a way to have backgroundrb start/stop with the > same UID that dispatch.fcgi uses, at the same point in time that apache is > started/stopped. I see a technique that seems plausable in this archive > message: > > http://rubyforge.org/pipermail/backgroundrb-devel/2007-February/000723.html > > which addresses the starting aspect, in a lazy fashion. That seems fine, > particularly given it's resilience to unexpected terminations of the > backgroundrb processes. > > What I have not seen any discussion of is how to insure that backgroundrb is > terminated (ideally cleanly) at the point in time that apache (or whatever > web server you use) is terminated. In other words, I am hoping to use > "apachectl {start|stop}" to control dispatch.fcgi and backgroundrb. > > Does anyone have any suggestions? In response to my own message, but in hopes of either being told that I am doing idiotic things, or helping others with the same problem, here is the solution that I have finally come up with. My answer was to use the following code within my config/environment.rb file: require 'pathname' BACKGROUNDRB_STANDALONE = false BACKGROUNDRB_ROOT = Pathname.new(RAILS_ROOT).realpath.to_s BACKGROUNDRB_CODE = BACKGROUNDRB_ROOT + '/vendor/plugins/backgroundrb' $LOAD_PATH << File.join(BACKGROUNDRB_CODE + '/lib') $LOAD_PATH << File.join(BACKGROUNDRB_CODE + '/server/lib') require 'backgroundrb_server' Process.fork { # Code lifted from script/backgroundrb ARGV.clear ARGV << 'start' exit(0) if File.exists?(BACKGROUNDRB_ROOT + '/log/backgroundrb.ppid'); BackgrounDRb::Server.new.run } at_exit { ARGV.clear ARGV << 'stop' exit(0) unless File.exists?(BACKGROUNDRB_ROOT + '/log/backgroundrb.ppid'); BackgrounDRb::Server.new.run } For reasons not understood at this time, I am finding that invoking script/backgroundrb {start|stop} does not work. Copying chunks of the code as shown above, does. Yes, there are some holes, such as relying on the ppid file and not checking if the pid is actually running; such as relying on at_exit to perform proper cleanup; such as not cleaning up open file descriptors in the forked child prior to calling run. If you have better suggestions, I would love to hear them. Thanks in advance - Marc From kovacs at gmail.com Tue Feb 27 15:02:01 2007 From: kovacs at gmail.com (Michael Kovacs) Date: Tue, 27 Feb 2007 12:02:01 -0800 Subject: [Backgroundrb-devel] Deploying to production with backgroundrb (capistrano) In-Reply-To: References: Message-ID: Hey Ez, Is there some reason why the stop task doesn't just use nohup to invoke the stop process in the backgroundrb script? I was going to add these to my deploy.rb and noticed that. As always thanks for your awesome work with backgroundrb and your help. Has anyone else used these tasks in their deploy.rb? -Michael http://javathehutt.blogspot.com On Feb 5, 2007, at 11:22 AM, Ezra Zygmuntowicz wrote: > Hey Jerrod- > > You need to use nohup in your tasks to start bdrb. > > task :before_restart, :roles => :app do > restart_backgroundrb > end > > task :start_backgroundrb, :roles => :app do > sudo "nohup /data/#{application}/current/script/backgroundrb > start " > end > > task :stop_backgroundrb, :roles => :app do > sudo "kill -9 `cat /data/#{application}/current/log/ > backgroundrb.pid` 2>/dev/null; true" > end > > task :restart_backgroundrb, :roles => :app do > stop_backgroundrb > start_backgroundrb > end > > Cheers- > -Ezra > > On Feb 5, 2007, at 10:48 AM, Jerrod Blavos wrote: > >> I have noticed that occasionally (about 50% of the time) when i >> deploy (using capistrano) my app to a production server, i have to >> ssh into the box and manually >> stop and start backgroundrb to get it to load my workers. >> >> this is my basic setup >> >> i have 2 workers: >> >> lib/workers/mp3_worker.rb => takes a hash of params to downsample >> an mp3 >> lib/workers/flv_worker.rb => takes a has of arguments to compose >> a command line to convert a file into flv >> >> in my recipe >> config/deploy.rb >> >> i have 2 lines >> run "#{current_path}/script/backgroundrb stop" >> run "#{current_path}/script/backgroundrb start" >> >> that should stop the server and restart it. >> >> after the deploy, i have started sshing in tot he box and running >> >> script/backgroundrb console >> >> and checking the loaded_worker_classes >> >> about 50% of the time, its empty. no classes loaded. >> >> if i manually run those commands, it starts and they load. >> identical command. different (and upredictable) results. >> >> how would i go about ensuring that when i deploy that backgroundrb >> restarts properly? ideally i will only be restarting backgroundrb >> when i have model changes or worker class changes that would affect >> it's operation. >> >> >> Jerrod Blavos >> ph. 919.341.0143 >> fx. 482.492.5009 >> jerrod at indierockmedia.com >> >> >> >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > -- Ezra Zygmuntowicz > -- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From ezmobius at gmail.com Tue Feb 27 15:55:28 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Tue, 27 Feb 2007 12:55:28 -0800 Subject: [Backgroundrb-devel] Deploying to production with backgroundrb (capistrano) In-Reply-To: References: Message-ID: Yeah the reason is thast nohup is not needed when you start bdrb from the machine its runing on. It's only needed when calling it via capistrano because if you don't use nohup when cap disconnects from the server the bdrb will get killed. It's an annoying little issue that the only workaround is to call it with nohup when calling it from cap. -Ezra On Feb 27, 2007, at 12:02 PM, Michael Kovacs wrote: > Hey Ez, > > Is there some reason why the stop task doesn't just use nohup to > invoke the stop process in the backgroundrb script? > I was going to add these to my deploy.rb and noticed that. > > As always thanks for your awesome work with backgroundrb and your > help. Has anyone else used these tasks in their deploy.rb? > > -Michael > http://javathehutt.blogspot.com > > On Feb 5, 2007, at 11:22 AM, Ezra Zygmuntowicz wrote: > >> Hey Jerrod- >> >> You need to use nohup in your tasks to start bdrb. >> >> task :before_restart, :roles => :app do >> restart_backgroundrb >> end >> >> task :start_backgroundrb, :roles => :app do >> sudo "nohup /data/#{application}/current/script/backgroundrb >> start " >> end >> >> task :stop_backgroundrb, :roles => :app do >> sudo "kill -9 `cat /data/#{application}/current/log/ >> backgroundrb.pid` 2>/dev/null; true" >> end >> >> task :restart_backgroundrb, :roles => :app do >> stop_backgroundrb >> start_backgroundrb >> end >> >> Cheers- >> -Ezra >> >> On Feb 5, 2007, at 10:48 AM, Jerrod Blavos wrote: >> >>> I have noticed that occasionally (about 50% of the time) when i >>> deploy (using capistrano) my app to a production server, i have to >>> ssh into the box and manually >>> stop and start backgroundrb to get it to load my workers. >>> >>> this is my basic setup >>> >>> i have 2 workers: >>> >>> lib/workers/mp3_worker.rb => takes a hash of params to downsample >>> an mp3 >>> lib/workers/flv_worker.rb => takes a has of arguments to compose >>> a command line to convert a file into flv >>> >>> in my recipe >>> config/deploy.rb >>> >>> i have 2 lines >>> run "#{current_path}/script/backgroundrb stop" >>> run "#{current_path}/script/backgroundrb start" >>> >>> that should stop the server and restart it. >>> >>> after the deploy, i have started sshing in tot he box and running >>> >>> script/backgroundrb console >>> >>> and checking the loaded_worker_classes >>> >>> about 50% of the time, its empty. no classes loaded. >>> >>> if i manually run those commands, it starts and they load. >>> identical command. different (and upredictable) results. >>> >>> how would i go about ensuring that when i deploy that backgroundrb >>> restarts properly? ideally i will only be restarting backgroundrb >>> when i have model changes or worker class changes that would affect >>> it's operation. >>> >>> >>> Jerrod Blavos >>> ph. 919.341.0143 >>> fx. 482.492.5009 >>> jerrod at indierockmedia.com >>> >>> >>> >>> _______________________________________________ >>> Backgroundrb-devel mailing list >>> Backgroundrb-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel >> >> -- Ezra Zygmuntowicz >> -- Lead Rails Evangelist >> -- ez at engineyard.com >> -- Engine Yard, Serious Rails Hosting >> -- (866) 518-YARD (9273) >> >> >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From medha_19 at yahoo.com Tue Feb 27 23:31:17 2007 From: medha_19 at yahoo.com (medha kulkarni) Date: Tue, 27 Feb 2007 20:31:17 -0800 (PST) Subject: [Backgroundrb-devel] backgroundrb 0.2.1 not supported on windows platform? Message-ID: <97781.81693.qm@web50108.mail.yahoo.com> Hi all, I want to execute certain ruby script periodically in my rails application running on windows platform. I wanted to try out backgroundrb, but it seems that the support for Windows is deprecated with release 0.2.0 of BackgrounDRb. The latest release is 0.2.1 & the plugin still doesnt support windows platform. Can anyone throw more light on this? Also, can anyone suggest any alternative approach to run ruby script periodically in rails application on windows platform? Thanks in advance! --------------------------------- With Best Regards, Medha. ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From david.gurba at gmail.com Wed Feb 28 02:13:05 2007 From: david.gurba at gmail.com (David Gurba) Date: Tue, 27 Feb 2007 23:13:05 -0800 Subject: [Backgroundrb-devel] example for standalone? Message-ID: Hi, I have a web based project management app I have written using Camping. It can take existing web projects from zip, expand them temporarily, create a repo and import all the content into the repo. Anyone know of any examples (even the ones in /examples) that are for using Backgroundrb in standalone mode .... I'm kinda having some trouble integrating this into my application. 1) if backgroundrb is in ~/project_managment_app/lib/backgroundrb ... where do /config and /worker dirs go ...trying rake backgroundrb:setup blew chunks 2) I assume my config.yml should have false for :load_rails and not set an :enviroment value ? thanks for any help in this regard. -davidg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070227/b656d3fb/attachment-0001.html From jacob at jacobatzen.dk Wed Feb 28 04:34:14 2007 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Wed, 28 Feb 2007 10:34:14 +0100 Subject: [Backgroundrb-devel] Backgroundrb weirdness with multiple mongrels In-Reply-To: <20070130142549.GA83695@apoc.jacobatzen.dk> References: <20070130142549.GA83695@apoc.jacobatzen.dk> Message-ID: <20070228093414.GA11580@apoc.jacobatzen.dk> On Tue, Jan 30, 2007 at 03:25:49PM +0100, Jacob Atzen wrote: > Hi list, > > I'm having some issues getting backgroundrb to play nice with more than > one mongrel. When I run my app on a single mongrel instance it works > fine. > > I have two different problems show up in my backgrounrb_server.log. The > top of the backtrace is shown here: [snip] > As can be seen it seems to stem from a call to new_worker. Though the > issue also seems to prop up when requesting an existing worker. > > Any ideas on where I should start to look? A little update on this. It seems that I can instantiate as many workers as I want from one process. But when I hit another process it will fail within a few requests, something like: localhost:3000/new_worker localhost:3000/new_worker localhost:3000/new_worker localhost:3000/new_worker localhost:3001/new_worker localhost:3001/new_worker localhost:3001/new_worker *boom* If I only instantiate one worker and reuse it across requests there seems to be no problem. Am I the only one experiencing this? -- Thanks, - Jacob Atzen From Marc at SoftwareHackery.Com Wed Feb 28 08:41:52 2007 From: Marc at SoftwareHackery.Com (Marc Evans) Date: Wed, 28 Feb 2007 08:41:52 -0500 (EST) Subject: [Backgroundrb-devel] IOError problem Message-ID: <20070228083638.C35238@me.softwarehackery.com> Hello - Can anyone explain why I get the stack trace in background_server.log when I try to start my first worker? I don't get this on subsequent workers, only the first one. I should note, the method I am using to start backgroundrb is documented in the archives, and is likely the root of this problem. Suggestions about how to "fix" or avoid this issue are appreciated. http://rubyforge.org/pipermail/backgroundrb-devel/2007-February/000756.html Thanks in advance - Marc 20070228-13:36:12 (9128) closed stream - (IOError) 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/logger.rb:504:in `write' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/logger.rb:504:in `write' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/monitor.rb:238:in `synchronize' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/logger.rb:496:in `write' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/logger.rb:326:in `add' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/logger.rb:374:in `info' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/abstract/connection_specification.rb:262:in `log_connections' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/abstract/connection_specification.rb:51:in `allow_concurrency=' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/../vendor/plugins/backgroundrb/server/lib/backgroundrb/worker_rails.rb:20:in `initialize' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in `new' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in `new_worker' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `initialize' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `new' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `dispatch' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in `new_worker' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1555:in `__send__' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1555:in `perform_without_block' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1515:in `perform' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1585:in `loop' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1581:in `start' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1430:in `run' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `start' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1347:in `initialize' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1627:in `new' 20070228-13:36:12 (9128) /usr/local/lib/ruby/1.8/drb/drb.rb:1627:in `start_service' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/../vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:315:in `run' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:186:in `call' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:186:in `start_proc' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/daemonize.rb:192:in `call' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/daemonize.rb:192:in `call_as_daemon' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:190:in `start_proc' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:226:in `start' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/controller.rb:69:in `run' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons.rb:182:in `run_proc' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/cmdline.rb:94:in `call' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/cmdline.rb:94:in `catch_exceptions' 20070228-13:36:12 (9128) /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons.rb:181:in `run_proc' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/../vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in `run' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/environment.rb:84 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/environment.rb:78:in `fork' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/../config/environment.rb:78 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/dispatch.fcgi:21:in `require' 20070228-13:36:12 (9128) /usr/local/www/data/cee/public/dispatch.fcgi:21 From steviec at gmail.com Wed Feb 28 14:53:56 2007 From: steviec at gmail.com (Stevie Clifton) Date: Wed, 28 Feb 2007 14:53:56 -0500 Subject: [Backgroundrb-devel] backgroundrb 0.2.1 not supported on windows platform? In-Reply-To: <97781.81693.qm@web50108.mail.yahoo.com> References: <97781.81693.qm@web50108.mail.yahoo.com> Message-ID: <2caed6660702281153k30a0898au2b7fd280bf977425@mail.gmail.com> Medha, To use backgroundrb on Windows you'll need to either run it under cygwin, or use a version pre 0.2.x. See this post by Ezra for the reasons behind this: http://rubyforge.org/pipermail/backgroundrb-devel/2006-November/000558.html I've been running backgroundrb 0.2.1 under cygwin on a windows box for the last couple of weeks and it's been working fine so far. I'm using it outside of the rails context so I can't comment on that one. stevie On 2/27/07, medha kulkarni wrote: > > Hi all, > > I want to execute certain ruby script periodically in > my rails application running on windows platform. > I wanted to try out backgroundrb, but it seems that > the support for Windows is deprecated with release > 0.2.0 of BackgrounDRb. > The latest release is 0.2.1 & the plugin still doesnt > support windows platform. Can anyone throw more light > on this? > > Also, can anyone suggest any alternative approach to > run ruby script periodically in rails application on > windows platform? > > Thanks in advance! > --------------------------------- > With Best Regards, > Medha. > > > > > ____________________________________________________________________________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Stevie Clifton stevie at slowbicycle.com 425-941-8642 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070228/9c7115b4/attachment.html From eden.li at gmail.com Wed Feb 28 22:17:09 2007 From: eden.li at gmail.com (Eden Li) Date: Thu, 1 Mar 2007 11:17:09 +0800 Subject: [Backgroundrb-devel] backgroundrb 0.2.1 not supported on windows platform? In-Reply-To: <97781.81693.qm@web50108.mail.yahoo.com> References: <97781.81693.qm@web50108.mail.yahoo.com> Message-ID: <565dbdd40702281917m32d7892fl3ab8cedf6f2a169@mail.gmail.com> If you just want to run a script periodically, backgroundrb might be overkill for you. Windows provides a cron-like service called "at". You can configure it on the commandline using "at" or via the Control Panel under Administrative Tools. More info at http://support.microsoft.com/kb/313289 On 2/28/07, medha kulkarni wrote: > Hi all, > > I want to execute certain ruby script periodically in > my rails application running on windows platform. > I wanted to try out backgroundrb, but it seems that > the support for Windows is deprecated with release > 0.2.0 of BackgrounDRb. > The latest release is 0.2.1 & the plugin still doesnt > support windows platform. Can anyone throw more light > on this? > > Also, can anyone suggest any alternative approach to > run ruby script periodically in rails application on > windows platform? > > Thanks in advance! > --------------------------------- > With Best Regards, > Medha. > > > > ____________________________________________________________________________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >