From prateek at muziboo.com Wed Jan 6 00:53:19 2010 From: prateek at muziboo.com (Prateek Dayal) Date: Wed, 6 Jan 2010 11:23:19 +0530 Subject: [Backgroundrb-devel] Weird thread behavior while using mp3info Message-ID: Hi, I have been using Backgroundrb for processing mp3 files in background for a long time but lately have been having a lot of problems. Here is my setup Rails --> Background Worker (using persistent queue) --> Defer to thread pool and process mp3 I am using ruby-mp3info gem to open the mp3 file and extract bitrate etc from it. This setup works fine but once in a while randomly stops working. Once one job fails, all subsequent jobs fails until I restart backgroundrb server. Here is the backtrace for all failed jobs /usr/lib/ruby/gems/1.8/gems/ruby-mp3info-0.6.13/lib/mp3info.rb:209:in `reload' /usr/lib/ruby/gems/1.8/gems/ruby-mp3info-0.6.13/lib/mp3info.rb:204:in `initialize' /usr/lib/ruby/gems/1.8/gems/ruby-mp3info-0.6.13/lib/mp3info.rb:327:in `new' /usr/lib/ruby/gems/1.8/gems/ruby-mp3info-0.6.13/lib/mp3info.rb:327:in `open' /home/rails/apps/muziboo/releases/20091230043630/lib/workers/background_worker.rb:178:in `process_mp3' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:94:in `send' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:94:in `run_task' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:76:in `add_thread' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:62:in `initialize' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:62:in `new' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:62:in `add_thread' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:27:in `initialize' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:27:in `times' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:27:in `initialize' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/meta_worker.rb:115:in `new' /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/meta_worker.rb:115:in `worker_init' /usr/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet_worker.rb:19:in `start_worker' /usr/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:33:in `load_worker' /usr/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:26:in `initialize' /usr/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:47:in `new' /usr/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:47 /usr/bin/packet_worker_runner:19:in `load' /usr/bin/packet_worker_runner:19 Line 209 in mp3info.rb is # reload (or load for the first time) the file from disk def reload raise(Mp3InfoError, "empty file") unless File.size?(@filename) # Line 209 @header = {} The Mp3 File is never size 0 (this is already checked in attachment_fu) so the exception should never be raised. I have tried checking hte filesize in console for failing files and the size is reported back correctly. As I said earlier, every subsequent job fails with the same error message untill I restart backgroundrb. Once I restart the server, these jobs all go through without a problem. I would appreciate any help with this as I have not been able to find much info on the net. I assumed that most of ruby's basic library functions (like File.size?) etc would work fine in the threaded environment. Regards, -- Prateek Dayal Co-Founder Muziboo.com Personal Blog: http://www.prateekdayal.net/blog Muziboo Dev Blog: http://devblog.muziboo.com From prateek at muziboo.com Wed Jan 6 01:34:24 2010 From: prateek at muziboo.com (Prateek Dayal) Date: Wed, 6 Jan 2010 12:04:24 +0530 Subject: [Backgroundrb-devel] Weird thread behavior while using mp3info In-Reply-To: <9f2cd26d1001052232k6c317802i4397f019c16fa70b@mail.gmail.com> References: <9f2cd26d1001052232k6c317802i4397f019c16fa70b@mail.gmail.com> Message-ID: Hi Raghavendra, I am rescuing the exception (and thats where I send the backtrace to the logger). Even with the exception rescued, all later tasks fail with the same exception Regards Prateek On Wed, Jan 6, 2010 at 12:02 PM, raghavendra gada wrote: > Hi, > > You can rescue the exception. > > Regards, > Raghu > > On Wed, Jan 6, 2010 at 11:23 AM, Prateek Dayal wrote: >> >> Hi, >> >> I have been using Backgroundrb for processing mp3 files in background >> for a long time but lately have been having a lot of problems. Here is >> my setup >> >> Rails --> Background Worker (using persistent queue) --> Defer to >> thread pool and process mp3 >> >> I am using ruby-mp3info gem to open the mp3 file and extract bitrate >> etc from it. This setup works fine but once in a while randomly stops >> working. Once one job fails, all subsequent jobs fails until I restart >> backgroundrb server. Here is the backtrace for all failed jobs >> >> /usr/lib/ruby/gems/1.8/gems/ruby-mp3info-0.6.13/lib/mp3info.rb:209:in >> `reload' >> /usr/lib/ruby/gems/1.8/gems/ruby-mp3info-0.6.13/lib/mp3info.rb:204:in >> `initialize' >> /usr/lib/ruby/gems/1.8/gems/ruby-mp3info-0.6.13/lib/mp3info.rb:327:in >> `new' >> /usr/lib/ruby/gems/1.8/gems/ruby-mp3info-0.6.13/lib/mp3info.rb:327:in >> `open' >> >> /home/rails/apps/muziboo/releases/20091230043630/lib/workers/background_worker.rb:178:in >> `process_mp3' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:94:in >> `send' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:94:in >> `run_task' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:76:in >> `add_thread' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:62:in >> `initialize' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:62:in >> `new' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:62:in >> `add_thread' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:27:in >> `initialize' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:27:in >> `times' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/bdrb_thread_pool.rb:27:in >> `initialize' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/meta_worker.rb:115:in >> `new' >> >> /home/rails/apps/muziboo/releases/20091230043630/vendor/plugins/backgroundrb/server/lib/meta_worker.rb:115:in >> `worker_init' >> >> /usr/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet_worker.rb:19:in >> `start_worker' >> /usr/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:33:in >> `load_worker' >> /usr/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:26:in >> `initialize' >> /usr/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:47:in >> `new' >> /usr/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner:47 >> /usr/bin/packet_worker_runner:19:in `load' >> /usr/bin/packet_worker_runner:19 >> >> Line 209 in mp3info.rb is >> >> >> ?# reload (or load for the first time) the file from disk >> ?def reload >> ? ?raise(Mp3InfoError, "empty file") unless File.size?(@filename) # Line >> 209 >> >> ? ?@header = {} >> >> The Mp3 File is never size 0 (this is already checked in >> attachment_fu) so the exception should never be raised. I have tried >> checking hte filesize in console for failing files and the size is >> reported back correctly. As I said earlier, every subsequent job fails >> with the same error message untill I restart backgroundrb. ?Once I >> restart the server, these jobs all go through without a problem. >> >> I would appreciate any help with this as I have not been able to find >> much info on the net. I assumed that most of ruby's basic library >> functions (like File.size?) etc would work fine in the threaded >> environment. >> >> >> Regards, >> >> -- >> Prateek Dayal >> Co-Founder Muziboo.com >> >> Personal Blog: ? ? ? http://www.prateekdayal.net/blog >> Muziboo Dev Blog: http://devblog.muziboo.com >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > -- Prateek Dayal Co-Founder Muziboo.com Personal Blog: http://www.prateekdayal.net/blog Muziboo Dev Blog: http://devblog.muziboo.com From nick at bytemark.co.uk Tue Jan 12 08:48:13 2010 From: nick at bytemark.co.uk (Nicholas Thomas) Date: Tue, 12 Jan 2010 13:48:13 +0000 Subject: [Backgroundrb-devel] Rails after_initialize block doesn't seem to be run in the backgroundrb context Message-ID: <1263304093.21215.5.camel@desk4.office.bytemark.co.uk> Hi all, Just had an interesting production failure while updating my Rails application - a bunch of code previously in config/environment.rb was put into config/initializers. That resulted in me having to wrap some code in config/environments/production.rb into an after_initialize do ... end block When backgroundrb was run against that code, the setup done in that after_initialize block wasn't run, leading to a failure in several background jobs that required it. Two purposes for the email - firstly, a heads-up that this is a problem, in case anyone else ends up bashing their heads against it. Secondly, anyone know how to /fix/ this? I've worked around it for now by moving the wrapped code into config/environment.rb, after Rails::Initializer do... end, wrapped in an if RAILS_ENV=production do ... end block - which is hardly ideal, although it has the advantage of working for now... ;) /Nick From adam at thewilliams.ws Tue Jan 12 09:19:53 2010 From: adam at thewilliams.ws (Adam Williams) Date: Tue, 12 Jan 2010 09:19:53 -0500 Subject: [Backgroundrb-devel] Rails after_initialize block doesn't seem to be run in the backgroundrb context In-Reply-To: <1263304093.21215.5.camel@desk4.office.bytemark.co.uk> References: <1263304093.21215.5.camel@desk4.office.bytemark.co.uk> Message-ID: <9B4CEB16-1050-400C-A3D7-5A2C7950C8D7@thewilliams.ws> Nick, I am convinced at this point that it's time to move on to Delayed Job. For one thing, Engine Yard strongly discourages the use of backgroundrb, and will not allow it at all on their cloud servers. I have made a great deal of effort to have as little code as possible in the workers already (good design practice to put business work in models - backgroundrb is an implementation detail), so making the migration should be relatively easy. There are some strange behaviors in backgroundrb, like this, that make it quite frustrating (for instance, how in the world does one make the logging work??). Coupled with the lack of current development (understandable), it seems to make sense to move on to more supported/encouraged technology. I know that doesn't help, but just in case you were considering the move already :) Adam Williams On Jan 12, 2010, at 8:48 AM, Nicholas Thomas wrote: > Hi all, > > Just had an interesting production failure while updating my Rails > application - a bunch of code previously in config/environment.rb was > put into config/initializers. That resulted in me having to wrap some > code in config/environments/production.rb into an after_initialize > do ... end block > > When backgroundrb was run against that code, the setup done in that > after_initialize block wasn't run, leading to a failure in several > background jobs that required it. > > Two purposes for the email - firstly, a heads-up that this is a problem, > in case anyone else ends up bashing their heads against it. Secondly, > anyone know how to /fix/ this? I've worked around it for now by moving > the wrapped code into config/environment.rb, after Rails::Initializer > do... end, wrapped in an if RAILS_ENV=production do ... end block - > which is hardly ideal, although it has the advantage of working for > now... ;) > > /Nick > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From christoforever at gmail.com Thu Jan 21 09:35:25 2010 From: christoforever at gmail.com (Christopher Dancy) Date: Thu, 21 Jan 2010 09:35:25 -0500 Subject: [Backgroundrb-devel] What do created processes do after finishing execution? Message-ID: <37dffd861001210635j1949be34i8ad4928c1dca596a@mail.gmail.com> I've looked around for answers on this and have found none ... or maybe I'm just missing something. After a process is created and is running ... what is it doing? Meaning, after it has finished processing does it sleep and wait for someone to call a method on it? does it still consume cpu time? -------------- next part -------------- An HTML attachment was scrubbed... URL: