From robert.bjarnason at gmail.com Thu Jan 4 11:44:40 2007 From: robert.bjarnason at gmail.com (Robert Bjarnason) Date: Thu, 04 Jan 2007 16:44:40 +0000 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb Message-ID: <459D2EF8.1010902@gmail.com> Hi, I'm using backgroundrb 0.2.1 in a production environment and for most parts I'm very happy. We are using it to do some heavy video editing on the server side and it works great except that under, what seems heavy load the below problem happens intermittently. The problem has only happened 5 times out of over 500 runs by our backgroundrb worker. This is the code in our worker: logger.debug("info : progress: #{progress}") progress_percent = progress * 100 if progress_percent >= 100 results[:progress] = 99.99 else results[:progress] = progress_percent <-- Line of the crash end Here is the error: can't convert Float into Hash And the beginning of the stack trace: /.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 :in `merge!'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 :in `[]='/.../ContentStore/lib/workers/content_worker.rb:40 :in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:22: in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:21 :in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:181 :in `do_work'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:55: ... The problem seems to happen only under heavy load where more than 1 worker process is active at the same time. Any ideas or leads? Thanks, Robert Bjarnason From hutch at recursive.ca Sat Jan 6 08:13:53 2007 From: hutch at recursive.ca (Bob Hutchison) Date: Sat, 6 Jan 2007 08:13:53 -0500 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb In-Reply-To: <459D2EF8.1010902@gmail.com> References: <459D2EF8.1010902@gmail.com> Message-ID: <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> Hi, This sounds a bit like the trouble in OS X where you'd get a Fixednum to String error. This was caused by a bug in the gcc 4.0 compiler. The solution on OS X is to re-compile Ruby with -O1 optimisation level or switch to the gcc 3.x compiler). As I understand it, with linux you have the additional option of installing a newer version of gcc 4.x and recompiling (I'm using 4.0.2 on one of my linux boxes and have never seen the problem). Cheers, Bob On 4-Jan-07, at 11:44 AM, Robert Bjarnason wrote: > Hi, > > I'm using backgroundrb 0.2.1 in a production environment and for most > parts I'm very happy. We are using it to do some heavy video > editing on > the server side and it works great except that under, what seems heavy > load the below problem happens intermittently. > > The problem has only happened 5 times out of over 500 runs by our > backgroundrb worker. > > This is the code in our worker: > logger.debug("info : progress: #{progress}") > progress_percent = progress * 100 > if progress_percent >= 100 > results[:progress] = 99.99 > else > results[:progress] = progress_percent <-- Line of > the crash > end > > Here is the error: > can't convert Float into Hash > > And the beginning of the stack trace: > /.../ContentStore/vendor/plugins/backgroundrb/server/lib/ > backgroundrb/results.rb:40 > :in > `merge!'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/ > backgroundrb/results.rb:40 > :in `[]='/.../ContentStore/lib/workers/content_worker.rb:40 > :in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb: > 22: > in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:21 > :in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb: > 181 > :in > `do_work'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/ > backgroundrb/worker.rb:55: > ... > > The problem seems to happen only under heavy load where more than 1 > worker process is active at the same time. > > Any ideas or leads? > > Thanks, > Robert Bjarnason > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel ---- Bob Hutchison -- blogs at Recursive Design Inc. -- Raconteur -- xampl for Ruby -- From robert.bjarnason at gmail.com Sun Jan 7 02:54:33 2007 From: robert.bjarnason at gmail.com (Robert Bjarnason) Date: Sun, 07 Jan 2007 07:54:33 +0000 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb In-Reply-To: <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> References: <459D2EF8.1010902@gmail.com> <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> Message-ID: <45A0A739.5030308@gmail.com> Hi Bob, Thanks for the pointer, I agree this is probably not a directly backgroundrb related problem. I built Ruby 1.8.4 on a Debian Linux box using gcc version 3.3.5. Warm regards, Robert Bjarnason Bob Hutchison wrote: > Hi, > > This sounds a bit like the trouble in OS X where you'd get a Fixednum > to String error. This was caused by a bug in the gcc 4.0 compiler. The > solution on OS X is to re-compile Ruby with -O1 optimisation level or > switch to the gcc 3.x compiler). As I understand it, with linux you > have the additional option of installing a newer version of gcc 4.x > and recompiling (I'm using 4.0.2 on one of my linux boxes and have > never seen the problem). > > Cheers, > Bob > > On 4-Jan-07, at 11:44 AM, Robert Bjarnason wrote: > >> Hi, >> >> I'm using backgroundrb 0.2.1 in a production environment and for most >> parts I'm very happy. We are using it to do some heavy video editing on >> the server side and it works great except that under, what seems heavy >> load the below problem happens intermittently. >> >> The problem has only happened 5 times out of over 500 runs by our >> backgroundrb worker. >> >> This is the code in our worker: >> logger.debug("info : progress: #{progress}") >> progress_percent = progress * 100 >> if progress_percent >= 100 >> results[:progress] = 99.99 >> else >> results[:progress] = progress_percent <-- Line of the >> crash >> end >> >> Here is the error: >> can't convert Float into Hash >> >> And the beginning of the stack trace: >> /.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 >> >> :in >> `merge!'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 >> >> :in `[]='/.../ContentStore/lib/workers/content_worker.rb:40 >> :in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:22: >> in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:21 >> :in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:181 >> :in >> `do_work'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:55: >> >> ... >> >> The problem seems to happen only under heavy load where more than 1 >> worker process is active at the same time. >> >> Any ideas or leads? >> >> Thanks, >> Robert Bjarnason >> >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > ---- > Bob Hutchison -- blogs at > > Recursive Design Inc. -- > Raconteur -- > xampl for Ruby -- > > > > From masonhale at gmail.com Tue Jan 9 15:54:44 2007 From: masonhale at gmail.com (Mason Hale) Date: Tue, 9 Jan 2007 14:54:44 -0600 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb In-Reply-To: <45A0A739.5030308@gmail.com> References: <459D2EF8.1010902@gmail.com> <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> <45A0A739.5030308@gmail.com> Message-ID: <8bca3aa10701091254r6385b3e7i4dc8851785c175cc@mail.gmail.com> I'm getting a similar error, here a partial stack trace: 20070108-20:17:45 (27597) can't convert Symbol into Hash - (TypeError) 20070108-20:17:45 (27597) /opt/lss/demo/0.4-06/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40:in `merge!' 20070108-20:17:45 (27597) /opt/lss/demo/0.4-06/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40:in `[]=' The process will run fine for hours or days, but then will stop with this error. When it happens it takes now the entire BackgrounDRb server. (I'm addding some begin/rescue blocks to hopefully prevent that.) I've got Ruby 1.8.5p12 compiled with gcc 3.4.6 on RedHat Linux. This also seems to occur with more than one process (running the same worker class) at the same tim Any ideas? Mason On 1/7/07, Robert Bjarnason wrote: > > Hi Bob, > > Thanks for the pointer, I agree this is probably not a directly > backgroundrb related problem. I built Ruby 1.8.4 on a Debian Linux box > using gcc version 3.3.5. > > Warm regards, > Robert Bjarnason > > Bob Hutchison wrote: > > Hi, > > > > This sounds a bit like the trouble in OS X where you'd get a Fixednum > > to String error. This was caused by a bug in the gcc 4.0 compiler. The > > solution on OS X is to re-compile Ruby with -O1 optimisation level or > > switch to the gcc 3.x compiler). As I understand it, with linux you > > have the additional option of installing a newer version of gcc 4.x > > and recompiling (I'm using 4.0.2 on one of my linux boxes and have > > never seen the problem). > > > > Cheers, > > Bob > > > > On 4-Jan-07, at 11:44 AM, Robert Bjarnason wrote: > > > >> Hi, > >> > >> I'm using backgroundrb 0.2.1 in a production environment and for most > >> parts I'm very happy. We are using it to do some heavy video editing > on > >> the server side and it works great except that under, what seems heavy > >> load the below problem happens intermittently. > >> > >> The problem has only happened 5 times out of over 500 runs by our > >> backgroundrb worker. > >> > >> This is the code in our worker: > >> logger.debug("info : progress: #{progress}") > >> progress_percent = progress * 100 > >> if progress_percent >= 100 > >> results[:progress] = 99.99 > >> else > >> results[:progress] = progress_percent <-- Line of the > >> crash > >> end > >> > >> Here is the error: > >> can't convert Float into Hash > >> > >> And the beginning of the stack trace: > >> > /.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 > >> > >> :in > >> > `merge!'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 > >> > >> :in `[]='/.../ContentStore/lib/workers/content_worker.rb:40 > >> :in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:22: > >> in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:21 > >> :in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:181 > >> :in > >> > `do_work'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:55: > >> > >> ... > >> > >> The problem seems to happen only under heavy load where more than 1 > >> worker process is active at the same time. > >> > >> Any ideas or leads? > >> > >> Thanks, > >> Robert Bjarnason > >> > >> _______________________________________________ > >> Backgroundrb-devel mailing list > >> Backgroundrb-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > ---- > > Bob Hutchison -- blogs at > > > > Recursive Design Inc. -- > > Raconteur -- > > xampl for Ruby -- > > > > > > > > > > _______________________________________________ > 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/20070109/f8c01274/attachment.html From robert.bjarnason at gmail.com Tue Jan 9 22:21:08 2007 From: robert.bjarnason at gmail.com (Robert Bjarnason) Date: Wed, 10 Jan 2007 03:21:08 +0000 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb In-Reply-To: <8bca3aa10701091254r6385b3e7i4dc8851785c175cc@mail.gmail.com> References: <459D2EF8.1010902@gmail.com> <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> <45A0A739.5030308@gmail.com> <8bca3aa10701091254r6385b3e7i4dc8851785c175cc@mail.gmail.com> Message-ID: <45A45BA4.3080705@gmail.com> Hi Mason, I'm still seeing the same problem with Float but in my case the backgroundrb server keeps on running fine and as people can retry on the client side this is not a blocker problem for us at the moment. Compiler bugs are now less likely as you are using a different version of Ruby, GCC and a different Linux distribution. Maybe the lead here is the fact that in both our cases more than one backgroundrb process is running when the crash happens, this should make it easy to create a test case to be able to replicate the problem to this - unfortunately I've only had the pleasure of working with Ruby for a couple of months so don't think I have the expertise needed to debug this problem. As I understand backgroundrb then there would be two completely isolated Ruby VMs running our code so maybe this is a backgroundrb problem after all? Warm regards, Robert Bjarnason Mason Hale wrote: > I'm getting a similar error, here a partial stack trace: > > 20070108-20:17:45 (27597) can't convert Symbol into Hash - (TypeError) > 20070108-20:17:45 (27597) > /opt/lss/demo/0.4-06/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40:in > `merge!' > 20070108-20:17:45 (27597) > /opt/lss/demo/0.4-06/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40:in > `[]=' > > The process will run fine for hours or days, but then will stop with > this error. When it happens it takes now the entire BackgrounDRb > server. (I'm addding some begin/rescue blocks to hopefully prevent that.) > > I've got Ruby 1.8.5p12 compiled with gcc 3.4.6 on RedHat Linux. > > This also seems to occur with more than one process (running the same > worker class) at the same tim > > Any ideas? > > Mason > > On 1/7/07, *Robert Bjarnason* > wrote: > > Hi Bob, > > Thanks for the pointer, I agree this is probably not a directly > backgroundrb related problem. I built Ruby 1.8.4 on a Debian > Linux box > using gcc version 3.3.5. > > Warm regards, > Robert Bjarnason > > Bob Hutchison wrote: > > Hi, > > > > This sounds a bit like the trouble in OS X where you'd get a > Fixednum > > to String error. This was caused by a bug in the gcc 4.0 > compiler. The > > solution on OS X is to re-compile Ruby with -O1 optimisation > level or > > switch to the gcc 3.x compiler). As I understand it, with linux you > > have the additional option of installing a newer version of gcc 4.x > > and recompiling (I'm using 4.0.2 on one of my linux boxes and have > > never seen the problem). > > > > Cheers, > > Bob > > > > On 4-Jan-07, at 11:44 AM, Robert Bjarnason wrote: > > > >> Hi, > >> > >> I'm using backgroundrb 0.2.1 in a production environment and > for most > >> parts I'm very happy. We are using it to do some heavy video > editing on > >> the server side and it works great except that under, what > seems heavy > >> load the below problem happens intermittently. > >> > >> The problem has only happened 5 times out of over 500 runs by our > >> backgroundrb worker. > >> > >> This is the code in our worker: > >> logger.debug("info : progress: #{progress}") > >> progress_percent = progress * 100 > >> if progress_percent >= 100 > >> results[:progress] = 99.99 > >> else > >> results[:progress] = progress_percent <-- Line > of the > >> crash > >> end > >> > >> Here is the error: > >> can't convert Float into Hash > >> > >> And the beginning of the stack trace: > >> > /.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 > > >> > >> :in > >> > `merge!'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 > >> > >> :in `[]='/.../ContentStore/lib/workers/content_worker.rb:40 > >> :in > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:22: > >> in > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:21 > >> :in > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:181 > >> :in > >> > `do_work'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:55: > >> > >> ... > >> > >> The problem seems to happen only under heavy load where more > than 1 > >> worker process is active at the same time. > >> > >> Any ideas or leads? > >> > >> Thanks, > >> Robert Bjarnason > >> > >> _______________________________________________ > >> Backgroundrb-devel mailing list > >> Backgroundrb-devel at rubyforge.org > > >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > ---- > > Bob Hutchison -- blogs at > > > > Recursive Design Inc. -- > > Raconteur -- > > > xampl for Ruby -- > > > > > > > > > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > From skaar at waste.org Wed Jan 10 08:05:40 2007 From: skaar at waste.org (skaar) Date: Wed, 10 Jan 2007 07:05:40 -0600 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb In-Reply-To: <8bca3aa10701091254r6385b3e7i4dc8851785c175cc@mail.gmail.com> References: <459D2EF8.1010902@gmail.com> <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> <45A0A739.5030308@gmail.com> <8bca3aa10701091254r6385b3e7i4dc8851785c175cc@mail.gmail.com> Message-ID: <20070110130540.GC32570@waste.org> It might be that we have to introduce a mutex in the results worker where this happens. I'll try to get this reproduced sometime this weekend. /skaar * Mason Hale (masonhale at gmail.com) [070109 14:42]: > I'm getting a similar error, here a partial stack trace: > > 20070108-20:17:45 (27597) can't convert Symbol into Hash - (TypeError) > 20070108-20:17:45 (27597) > /opt/lss/demo/0.4-06/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40:in > `merge!' > 20070108-20:17:45 (27597) > /opt/lss/demo/0.4-06/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40:in > `[]=' > > The process will run fine for hours or days, but then will stop with this > error. When it happens it takes now the entire BackgrounDRb server. (I'm > addding some begin/rescue blocks to hopefully prevent that.) > > I've got Ruby 1.8.5p12 compiled with gcc 3.4.6 on RedHat Linux. > > This also seems to occur with more than one process (running the same > worker class) at the same tim > > Any ideas? > > Mason > > On 1/7/07, Robert Bjarnason <[1]robert.bjarnason at gmail.com> wrote: > > Hi Bob, > > Thanks for the pointer, I agree this is probably not a directly > backgroundrb related problem. I built Ruby 1.8.4 on a Debian Linux box > using gcc version 3.3.5. > > Warm regards, > Robert Bjarnason > > Bob Hutchison wrote: > > Hi, > > > > This sounds a bit like the trouble in OS X where you'd get a Fixednum > > to String error. This was caused by a bug in the gcc 4.0 compiler. The > > solution on OS X is to re-compile Ruby with -O1 optimisation level or > > switch to the gcc 3.x compiler). As I understand it, with linux you > > have the additional option of installing a newer version of gcc 4.x > > and recompiling (I'm using 4.0.2 on one of my linux boxes and have > > never seen the problem). > > > > Cheers, > > Bob > > > > On 4-Jan-07, at 11:44 AM, Robert Bjarnason wrote: > > > >> Hi, > >> > >> I'm using backgroundrb 0.2.1 in a production environment and for most > >> parts I'm very happy. We are using it to do some heavy video editing > on > >> the server side and it works great except that under, what seems > heavy > >> load the below problem happens intermittently. > >> > >> The problem has only happened 5 times out of over 500 runs by our > >> backgroundrb worker. > >> > >> This is the code in our worker: > >> logger.debug("info : progress: #{progress}") > >> progress_percent = progress * 100 > >> if progress_percent >= 100 > >> results[:progress] = 99.99 > >> else > >> results[:progress] = progress_percent <-- Line of the > >> crash > >> end > >> > >> Here is the error: > >> can't convert Float into Hash > >> > >> And the beginning of the stack trace: > >> > /.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 > >> > >> :in > >> > `merge!'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 > >> > >> :in `[]='/.../ContentStore/lib/workers/content_worker.rb:40 > >> :in > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:22: > >> in `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:21 > >> :in > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:181 > >> :in > >> > `do_work'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:55: > >> > >> ... > >> > >> The problem seems to happen only under heavy load where more than 1 > >> worker process is active at the same time. > >> > >> Any ideas or leads? > >> > >> Thanks, > >> Robert Bjarnason > >> > >> _______________________________________________ > >> Backgroundrb-devel mailing list > >> [2]Backgroundrb-devel at rubyforge.org > >> [3]http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > ---- > > Bob Hutchison -- blogs at > > <[4]http://www.recursive.ca/hutch/> > > Recursive Design Inc. -- <[5]http://www.recursive.ca/> > > Raconteur -- <[6]http://www.raconteur.info/ > > > xampl for Ruby -- > <[7]http://rubyforge.org/projects/xampl/> > > > > > > > > > > _______________________________________________ > Backgroundrb-devel mailing list > [8]Backgroundrb-devel at rubyforge.org > [9]http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > References > > Visible links > 1. mailto:robert.bjarnason at gmail.com > 2. mailto:Backgroundrb-devel at rubyforge.org > 3. http://rubyforge.org/mailman/listinfo/backgroundrb-devel > 4. http://www.recursive.ca/hutch/ > 5. http://www.recursive.ca/ > 6. http://www.raconteur.info/ > 7. http://rubyforge.org/projects/xampl/ > 8. mailto:Backgroundrb-devel at rubyforge.org > 9. http://rubyforge.org/mailman/listinfo/backgroundrb-devel > _______________________________________________ > 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 masonhale at gmail.com Wed Jan 10 14:39:11 2007 From: masonhale at gmail.com (Mason Hale) Date: Wed, 10 Jan 2007 13:39:11 -0600 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb In-Reply-To: <20070110130540.GC32570@waste.org> References: <459D2EF8.1010902@gmail.com> <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> <45A0A739.5030308@gmail.com> <8bca3aa10701091254r6385b3e7i4dc8851785c175cc@mail.gmail.com> <20070110130540.GC32570@waste.org> Message-ID: <8bca3aa10701101139v673c852cmce9388f517b2a8c2@mail.gmail.com> I've done some more work on this and have created a test case that reliably throws errors, although the errors themselves are not consistent. About 1 out of every 4 times, I get the "can't convert Symbol to Hash" error in server/lib/backgroundrb/results.rb:40 in 'merge!'. I created the following worker class is {RAILS_ROOT}/lib/workers/results_test_worker.rb # This class repeatedly writes values to the results, to # test the results process class ResultsTestWorker < BackgrounDRb::Worker::RailsBase def do_work(args) logger.info "Started ResultsTestWorker" results[:started_at] = Time.now args ||= {} limit = args[:limit] || 10_000 logger.info "Limit is #{limit}" limit.times do |i| results[:last_update] = Time.now results[:counter] = i end stop_time = Time.now logger.info "Stopped ResultsTestWorker at #{stop_time}" results[:stopped_at] = stop_time self.delete end end ResultsTestWorker.register Then in {RAILS_ROOT}/test/unit/drb_results_test.rb I have: require File.dirname(__FILE__) + '/../test_helper' class DrbResultsTest < Test::Unit::TestCase def setup # start backgroundrb server `../../script/backgroundrb start` sleep 5 # give it time to startup end def teardown # stop backgroundrb server `../../script/backgroundrb stop` end def test_results limit = 10 keys = [] 4.times do |i| job_key = "#{self.class.name}_#{i}" keys << job_key MiddleMan.new_worker(:class => :results_test_worker, :job_key => job_key, :args => {:limit => limit}) end sleep 2 # wait for workers to finish keys.each_with_index do |k, i| assert_not_nil MiddleMan[k], "checking job_key #{k} on iteration #{i}" assert_not_nil MiddleMan[k].object, "checking object on iteration #{i}" assert_not_nil MiddleMan[k].object.results, "checking results on iteration #{i}" assert_equal(limit - 1, MiddleMan[k].object.results.to_hash[:counter], "checking counter on iteration #{i}") end end end This test does the following: - Spawns 4 results_test_worker processes that each write several values to the ResultsWorker (in parallel) Increasing the limit value increases the odds of these processes concurrently trying to write results at the same time, but I've found that a limit of 10 works pretty well. - It waits a couple seconds for the workers to finish (is there a better way to determine if the processes are all done)? - Then it tries to access the results for each job_key, specifically to ensure that counter value is equal to limit - 1. NOTE: I've never gotten this test to complete successfully. In addition to the "can't convert Symbol to Hash" error, I've seen the following: - The [:counter] value is much lower than the expected value. If limit is 10,000 this value might be 246 when 9,999 was expected. - The job_key is not recognized, the call to MiddleMan[k] returns nil. When this occurs, I can usually see in the backgroundrb.log that fewer than 4 workers were actually created. I can see this by counting the number of "Started ResultsTestWorker" messages in the log. - The job_key is resolved, but the call to MiddleMan[k].object.results returns nil - The call to MiddleMan.new_worker hangs and never returns I'm sharing this code so that others can try it out. It's a bit of a hack to get some testing working (starting and stopping the BackgrounDRb server on each test, having a test worker class in lib/workers, etc.), but it is self-contained, and replicated the real-world environment of my code running in rails. It you have suggestions for improving the testing approach I'm all ears. I'm also interested in feedback in the code itself. Maybe I'm not working with the MiddleMan object correctly. I have to admit I'm still wrapping my head around Drb. Resolving this issue is critical to my project so I will continue trying to track things down. I'll start by adding a mutex to the Results#[]= method. Mason On 1/10/07, skaar wrote: > > It might be that we have to introduce a mutex in the results worker > where this happens. I'll try to get this reproduced sometime this > weekend. > > /skaar > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070110/bfd945b4/attachment.html From skaar at waste.org Wed Jan 10 16:05:01 2007 From: skaar at waste.org (skaar) Date: Wed, 10 Jan 2007 15:05:01 -0600 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb In-Reply-To: <8bca3aa10701101139v673c852cmce9388f517b2a8c2@mail.gmail.com> References: <459D2EF8.1010902@gmail.com> <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> <45A0A739.5030308@gmail.com> <8bca3aa10701091254r6385b3e7i4dc8851785c175cc@mail.gmail.com> <20070110130540.GC32570@waste.org> <8bca3aa10701101139v673c852cmce9388f517b2a8c2@mail.gmail.com> Message-ID: <20070110210501.GB16981@waste.org> I do have a test case that is close to this, which at this point has shown the exception once on a 10K result assignment with 4 workers. (Mason - could you a ticket for this?) * Mason Hale (masonhale at gmail.com) [070110 13:27]: > I've done some more work on this and have created a test case that > reliably throws errors, although the errors themselves are not consistent. > About 1 out of every 4 times, I get the "can't convert Symbol to Hash" > error in server/lib/backgroundrb/results.rb:40 in 'merge!'. > > keys.each_with_index do |k, i| > assert_not_nil MiddleMan[k], "checking job_key #{k} on iteration > #{i}" > assert_not_nil MiddleMan[k].object, "checking object on iteration > #{i}" > assert_not_nil MiddleMan[k].object.results, "checking results on > iteration #{i}" > assert_equal(limit - 1, > MiddleMan[k].object.results.to_hash[:counter], "checking counter on > iteration #{i}") > end > > end > end you should probably use MiddleMan.worker(k) here, which will benefit from the WorkerProxy (this is an inconsistency that I had overlooked) where you are re-directed directly to the results worker after the worker itself has gone away. so: MiddleMan.worker(k).results also MiddleMan.worker(k).results[:counter] should work as well. Another thing that worries me a little bit is that I see very different completion time. Everything from 10 minutes to almost 1/2 hour - that is with 4 x 10k results. /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 masonhale at gmail.com Wed Jan 10 16:22:17 2007 From: masonhale at gmail.com (Mason Hale) Date: Wed, 10 Jan 2007 15:22:17 -0600 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb In-Reply-To: <20070110210501.GB16981@waste.org> References: <459D2EF8.1010902@gmail.com> <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> <45A0A739.5030308@gmail.com> <8bca3aa10701091254r6385b3e7i4dc8851785c175cc@mail.gmail.com> <20070110130540.GC32570@waste.org> <8bca3aa10701101139v673c852cmce9388f517b2a8c2@mail.gmail.com> <20070110210501.GB16981@waste.org> Message-ID: <8bca3aa10701101322j7f7972abg7e323caaca724fd5@mail.gmail.com> Thanks skaar. I'll add a ticket. FYI -- I'm running my tests on a Macbook, OS X 10.4 w/ Ruby 1.8.4 On 1/10/07, skaar wrote: > > I do have a test case that is close to this, which at this point has > shown the exception once on a 10K result assignment with 4 workers. > > (Mason - could you a ticket for this?) > > * Mason Hale (masonhale at gmail.com) [070110 13:27]: > > I've done some more work on this and have created a test case that > > reliably throws errors, although the errors themselves are not > consistent. > > About 1 out of every 4 times, I get the "can't convert Symbol to > Hash" > > error in server/lib/backgroundrb/results.rb:40 in 'merge!'. > > > > keys.each_with_index do |k, i| > > assert_not_nil MiddleMan[k], "checking job_key #{k} on > iteration > > #{i}" > > assert_not_nil MiddleMan[k].object, "checking object on > iteration > > #{i}" > > assert_not_nil MiddleMan[k].object.results, "checking results > on > > iteration #{i}" > > assert_equal(limit - 1, > > MiddleMan[k].object.results.to_hash[:counter], "checking counter on > > iteration #{i}") > > end > > > > end > > end > > you should probably use MiddleMan.worker(k) here, which will benefit > from the WorkerProxy (this is an inconsistency that I had overlooked) > where you are re-directed directly to the results worker after the > worker itself has gone away. so: > > MiddleMan.worker(k).results > > also > > MiddleMan.worker(k).results[:counter] > > should work as well. > > Another thing that worries me a little bit is that I see very different > completion time. Everything from 10 minutes to almost 1/2 hour - that is > with 4 x 10k results. > > /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 > ---------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070110/426bdb60/attachment-0001.html From robert.bjarnason at gmail.com Thu Jan 11 16:41:39 2007 From: robert.bjarnason at gmail.com (Robert Bjarnason) Date: Thu, 11 Jan 2007 21:41:39 +0000 Subject: [Backgroundrb-devel] Load balancing Message-ID: <45A6AF13.3070100@gmail.com> Hi, Can somebody point me in the right direction about what approach would be best to load-balance between two or more physical servers running backgroundrb while using BackgrounDRb::Worker::RailsBase with mongrel? Thanks, Robert Bjarnason From eimorton at gmail.com Thu Jan 11 17:20:36 2007 From: eimorton at gmail.com (Erik Morton) Date: Thu, 11 Jan 2007 17:20:36 -0500 Subject: [Backgroundrb-devel] Load balancing In-Reply-To: <45A6AF13.3070100@gmail.com> References: <45A6AF13.3070100@gmail.com> Message-ID: <36F895E0-FDD9-49D8-854F-7E9E750E4ACF@gmail.com> We chose to bypass MiddleMan and place our requests for workers into a queue. This way we can create an arbitrary number of workers that loop and ask the queue for work. The Mongrels have no need to know the location or number of workers. You will of course need another strategy to get progress/results from the workers. On Jan 11, 2007, at 4:41 PM, Robert Bjarnason wrote: > Hi, > > Can somebody point me in the right direction about what approach would > be best to load-balance between two or more physical servers running > backgroundrb while using BackgrounDRb::Worker::RailsBase with > mongrel? > > Thanks, > Robert Bjarnason > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From robert.bjarnason at gmail.com Thu Jan 11 18:01:13 2007 From: robert.bjarnason at gmail.com (Robert Bjarnason) Date: Thu, 11 Jan 2007 23:01:13 +0000 Subject: [Backgroundrb-devel] Load balancing In-Reply-To: <36F895E0-FDD9-49D8-854F-7E9E750E4ACF@gmail.com> References: <45A6AF13.3070100@gmail.com> <36F895E0-FDD9-49D8-854F-7E9E750E4ACF@gmail.com> Message-ID: <45A6C1B9.3050007@gmail.com> Hi Erik, Thanks for the pointer, I have used JavaSpaces in the past and really like this pattern. However, my workers are user initiated and trigger x264 and mp4box video encoding/editing processes and I'm planning to have a limit of 1-2 simulations backgroundrb processes running on each physical server. I have an entry in the database for each user initiated job, maybe I can add the IP of each backgroundrb server to that entry and do the load-balancing in Rails using the database? The question then is how do I dynamically change the backgroundrb server IP for each instantiated MiddleMan object? Warm regards, Robert Bjarnason ps. here are links to the sites that are currently using backgroundrb-2.1 more or less successfully in production mode: http://store.longwayround.com/ http://store.missingface.com/ http://store.racetodakar.com/ http://store.murderormutiny.com/ Erik Morton wrote: > We chose to bypass MiddleMan and place our requests for workers into a > queue. This way we can create an arbitrary number of workers that loop > and ask the queue for work. The Mongrels have no need to know the > location or number of workers. You will of course need another > strategy to get progress/results from the workers. > > On Jan 11, 2007, at 4:41 PM, Robert Bjarnason wrote: > >> Hi, >> >> Can somebody point me in the right direction about what approach would >> be best to load-balance between two or more physical servers running >> backgroundrb while using BackgrounDRb::Worker::RailsBase with mongrel? >> >> Thanks, >> Robert Bjarnason >> >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > From skaar at waste.org Thu Jan 11 19:06:50 2007 From: skaar at waste.org (skaar) Date: Thu, 11 Jan 2007 18:06:50 -0600 Subject: [Backgroundrb-devel] Load balancing In-Reply-To: <45A6C1B9.3050007@gmail.com> References: <45A6AF13.3070100@gmail.com> <36F895E0-FDD9-49D8-854F-7E9E750E4ACF@gmail.com> <45A6C1B9.3050007@gmail.com> Message-ID: <20070112000650.GB18716@waste.org> * Robert Bjarnason (robert.bjarnason at gmail.com) [070111 16:56]: > Hi Erik, > > Thanks for the pointer, I have used JavaSpaces in the past and really > like this pattern. > > However, my workers are user initiated and trigger x264 and mp4box video > encoding/editing processes and I'm planning to have a limit of 1-2 > simulations backgroundrb processes running on each physical server. > > I have an entry in the database for each user initiated job, maybe I can > add the IP of each backgroundrb server to that entry and do the > load-balancing in Rails using the database? The question then is how do > I dynamically change the backgroundrb server IP for each instantiated > MiddleMan object? you can use BackgrounDRb::MiddleManDRbObject and instead of calling the MiddleMan constant, use a regular object - actually it's a class method which takes a DRb uri as it's argument - behaves just like the MiddleMan. /skaar > > Warm regards, > Robert Bjarnason > > ps. here are links to the sites that are currently using > backgroundrb-2.1 more or less successfully in production mode: > http://store.longwayround.com/ > http://store.missingface.com/ > http://store.racetodakar.com/ > http://store.murderormutiny.com/ > > Erik Morton wrote: > > We chose to bypass MiddleMan and place our requests for workers into a > > queue. This way we can create an arbitrary number of workers that loop > > and ask the queue for work. The Mongrels have no need to know the > > location or number of workers. You will of course need another > > strategy to get progress/results from the workers. > > > > On Jan 11, 2007, at 4:41 PM, Robert Bjarnason wrote: > > > >> Hi, > >> > >> Can somebody point me in the right direction about what approach would > >> be best to load-balance between two or more physical servers running > >> backgroundrb while using BackgrounDRb::Worker::RailsBase with mongrel? > >> > >> Thanks, > >> Robert Bjarnason > >> > >> _______________________________________________ > >> 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 -- ---------------------------------------------------------------------- |\|\ 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 masonhale at gmail.com Fri Jan 12 12:57:37 2007 From: masonhale at gmail.com (Mason Hale) Date: Fri, 12 Jan 2007 11:57:37 -0600 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb In-Reply-To: <20070110130540.GC32570@waste.org> References: <459D2EF8.1010902@gmail.com> <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> <45A0A739.5030308@gmail.com> <8bca3aa10701091254r6385b3e7i4dc8851785c175cc@mail.gmail.com> <20070110130540.GC32570@waste.org> Message-ID: <8bca3aa10701120957o6bb49f10yb6af35dd796884c6@mail.gmail.com> Following up on this item, I found that if I remove any calls to add values to the results_worker hash, the errors described below go away. I also found that in some cases the call to 'BackgrouDRb::Results::stored' was returning the symbol :backgroundrb_results instead of a hash, thus triggering the "can't convert Symbol to Hash" TypeError. I made a pass at synchronizing the WorkerResults []= and [] methods via Mutex, but was unsuccessful. I suspect it may have something to do with Mutex not being reentrant. See: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/24470 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/172652 In any case, avoiding use of results avoids the issue. For the time being, I'm storing any process state information in a database instead. Mason On 1/10/07, skaar wrote: > > It might be that we have to introduce a mutex in the results worker > where this happens. I'll try to get this reproduced sometime this > weekend. > > /skaar > > > * Mason Hale (masonhale at gmail.com) [070109 14:42]: > > I'm getting a similar error, here a partial stack trace: > > > > 20070108-20:17:45 (27597) can't convert Symbol into Hash - > (TypeError) > > 20070108-20:17:45 (27597) > > > /opt/lss/demo/0.4-06/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40:in > > `merge!' > > 20070108-20:17:45 (27597) > > > /opt/lss/demo/0.4-06/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40:in > > `[]=' > > > > The process will run fine for hours or days, but then will stop with > this > > error. When it happens it takes now the entire BackgrounDRb server. > (I'm > > addding some begin/rescue blocks to hopefully prevent that.) > > > > I've got Ruby 1.8.5p12 compiled with gcc 3.4.6 on RedHat Linux. > > > > This also seems to occur with more than one process (running the same > > worker class) at the same tim > > > > Any ideas? > > > > Mason > > > > On 1/7/07, Robert Bjarnason <[1]robert.bjarnason at gmail.com> wrote: > > > > Hi Bob, > > > > Thanks for the pointer, I agree this is probably not a directly > > backgroundrb related problem. I built Ruby 1.8.4 on a Debian Linux > box > > using gcc version 3.3.5. > > > > Warm regards, > > Robert Bjarnason > > > > Bob Hutchison wrote: > > > Hi, > > > > > > This sounds a bit like the trouble in OS X where you'd get a > Fixednum > > > to String error. This was caused by a bug in the gcc 4.0compiler. The > > > solution on OS X is to re-compile Ruby with -O1 optimisation > level or > > > switch to the gcc 3.x compiler). As I understand it, with linux > you > > > have the additional option of installing a newer version of gcc > 4.x > > > and recompiling (I'm using 4.0.2 on one of my linux boxes and > have > > > never seen the problem). > > > > > > Cheers, > > > Bob > > > > > > On 4-Jan-07, at 11:44 AM, Robert Bjarnason wrote: > > > > > >> Hi, > > >> > > >> I'm using backgroundrb 0.2.1 in a production environment and for > most > > >> parts I'm very happy. We are using it to do some heavy video > editing > > on > > >> the server side and it works great except that under, what seems > > heavy > > >> load the below problem happens intermittently. > > >> > > >> The problem has only happened 5 times out of over 500 runs by > our > > >> backgroundrb worker. > > >> > > >> This is the code in our worker: > > >> logger.debug("info : progress: #{progress}") > > >> progress_percent = progress * 100 > > >> if progress_percent >= 100 > > >> results[:progress] = 99.99 > > >> else > > >> results[:progress] = progress_percent <-- Line > of the > > >> crash > > >> end > > >> > > >> Here is the error: > > >> can't convert Float into Hash > > >> > > >> And the beginning of the stack trace: > > >> > > > /.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 > > >> > > >> :in > > >> > > > `merge!'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 > > >> > > >> :in `[]='/.../ContentStore/lib/workers/content_worker.rb:40 > > >> :in > > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:22: > > >> in > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:21 > > >> :in > > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:181 > > >> :in > > >> > > > `do_work'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:55: > > >> > > >> ... > > >> > > >> The problem seems to happen only under heavy load where more > than 1 > > >> worker process is active at the same time. > > >> > > >> Any ideas or leads? > > >> > > >> Thanks, > > >> Robert Bjarnason > > >> > > >> _______________________________________________ > > >> Backgroundrb-devel mailing list > > >> [2]Backgroundrb-devel at rubyforge.org > > >> [3]http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > > ---- > > > Bob Hutchison -- blogs at > > > <[4]http://www.recursive.ca/hutch/> > > > Recursive Design Inc. -- <[5]http://www.recursive.ca/> > > > Raconteur -- <[6]http://www.raconteur.info/ > > > > > xampl for Ruby -- > > <[7]http://rubyforge.org/projects/xampl/> > > > > > > > > > > > > > > > > _______________________________________________ > > Backgroundrb-devel mailing list > > [8]Backgroundrb-devel at rubyforge.org > > [9]http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > References > > > > Visible links > > 1. mailto:robert.bjarnason at gmail.com > > 2. mailto:Backgroundrb-devel at rubyforge.org > > 3. http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > 4. http://www.recursive.ca/hutch/ > > 5. http://www.recursive.ca/ > > 6. http://www.raconteur.info/ > > 7. http://rubyforge.org/projects/xampl/ > > 8. mailto:Backgroundrb-devel at rubyforge.org > > 9. http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > _______________________________________________ > > 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/20070112/12cf3de9/attachment-0001.html From skaar at waste.org Fri Jan 12 15:29:09 2007 From: skaar at waste.org (skaar) Date: Fri, 12 Jan 2007 14:29:09 -0600 Subject: [Backgroundrb-devel] Intermittent "can't convert Float into Hash" and results.rb In-Reply-To: <8bca3aa10701120957o6bb49f10yb6af35dd796884c6@mail.gmail.com> References: <459D2EF8.1010902@gmail.com> <8558AE69-B79F-40FF-B5B8-BBD1518E1ACB@recursive.ca> <45A0A739.5030308@gmail.com> <8bca3aa10701091254r6385b3e7i4dc8851785c175cc@mail.gmail.com> <20070110130540.GC32570@waste.org> <8bca3aa10701120957o6bb49f10yb6af35dd796884c6@mail.gmail.com> Message-ID: <20070112202909.GA8505@waste.org> I'm going to try to use synchronize from Monitor, which is supposed to be reentrant. I just need to have a closer look on how the MonitorMixin works. /skaar * Mason Hale (masonhale at gmail.com) [070112 12:01]: > Following up on this item, I found that if I remove any calls to add > values to the results_worker hash, the errors described below go away. > > I also found that in some cases the call to 'BackgrouDRb::Results::stored' > was returning the symbol :backgroundrb_results instead of a hash, thus > triggering the "can't convert Symbol to Hash" TypeError. > > I made a pass at synchronizing the WorkerResults []= and [] methods via > Mutex, but was unsuccessful. I suspect it may have something to do with > Mutex not being reentrant. > > See: > [1]http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/24470 > [2]http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/172652 > > In any case, avoiding use of results avoids the issue. For the time being, > I'm storing any process state information in a database instead. > > Mason > > On 1/10/07, skaar <[3]skaar at waste.org> wrote: > > It might be that we have to introduce a mutex in the results worker > where this happens. I'll try to get this reproduced sometime this > weekend. > > /skaar > > * Mason Hale ([4]masonhale at gmail.com) [070109 14:42]: > > I'm getting a similar error, here a partial stack trace: > > > > 20070108-20:17:45 (27597) can't convert Symbol into Hash - > (TypeError) > > 20070108-20:17:45 (27597) > > /opt/lss/demo/0.4-06/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40:in > > `merge!' > > 20070108-20:17:45 (27597) > > /opt/lss/demo/0.4-06/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40:in > > `[]=' > > > > The process will run fine for hours or days, but then will stop > with this > > error. When it happens it takes now the entire BackgrounDRb server. > (I'm > > addding some begin/rescue blocks to hopefully prevent that.) > > > > I've got Ruby 1.8.5p12 compiled with gcc 3.4.6 on RedHat Linux. > > > > This also seems to occur with more than one process (running the > same > > worker class) at the same tim > > > > Any ideas? > > > > Mason > > > > On 1/7/07, Robert Bjarnason <[1]robert.bjarnason@ [5]gmail.com> > wrote: > > > > Hi Bob, > > > > Thanks for the pointer, I agree this is probably not a directly > > backgroundrb related problem. I built Ruby 1.8.4 on a Debian > Linux box > > using gcc version 3.3.5. > > > > Warm regards, > > Robert Bjarnason > > > > Bob Hutchison wrote: > > > Hi, > > > > > > This sounds a bit like the trouble in OS X where you'd get a > Fixednum > > > to String error. This was caused by a bug in the gcc 4.0 > compiler. The > > > solution on OS X is to re-compile Ruby with -O1 optimisation > level or > > > switch to the gcc 3.x compiler). As I understand it, with linux > you > > > have the additional option of installing a newer version of gcc > 4.x > > > and recompiling (I'm using 4.0.2 on one of my linux boxes and > have > > > never seen the problem). > > > > > > Cheers, > > > Bob > > > > > > On 4-Jan-07, at 11:44 AM, Robert Bjarnason wrote: > > > > > >> Hi, > > >> > > >> I'm using backgroundrb 0.2.1 in a production environment and > for most > > >> parts I'm very happy. We are using it to do some heavy video > editing > > on > > >> the server side and it works great except that under, what > seems > > heavy > > >> load the below problem happens intermittently. > > >> > > >> The problem has only happened 5 times out of over 500 runs by > our > > >> backgroundrb worker. > > >> > > >> This is the code in our worker: > > >> logger.debug("info : progress: #{progress}") > > >> progress_percent = progress * 100 > > >> if progress_percent >= 100 > > >> results[:progress] = 99.99 > > >> else > > >> results[:progress] = progress_percent <-- Line > of the > > >> crash > > >> end > > >> > > >> Here is the error: > > >> can't convert Float into Hash > > >> > > >> And the beginning of the stack trace: > > >> > > /.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 > > >> > > >> :in > > >> > > `merge!'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/results.rb:40 > > >> > > >> :in `[]='/.../ContentStore/lib/workers/content_worker.rb:40 > > >> :in > > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:22: > > >> in > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:21 > > >> :in > > `execute_mp4box'/.../ContentStore/lib/workers/content_worker.rb:181 > > >> :in > > >> > > `do_work'/.../ContentStore/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:55: > > >> > > >> ... > > >> > > >> The problem seems to happen only under heavy load where more > than 1 > > >> worker process is active at the same time. > > >> > > >> Any ideas or leads? > > >> > > >> Thanks, > > >> Robert Bjarnason > > >> > > >> _______________________________________________ > > >> Backgroundrb-devel mailing list > > >> [2]Backgroundrb-[6]devel at rubyforge.org > > >> [3]http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > > ---- > > > Bob Hutchison -- blogs at > > > <[4]http://www.recursive.ca/hutch/> > > > Recursive Design Inc. -- <[5]http://www.recursive.ca/> > > > Raconteur -- > <[6]http://www.raconteur.info/ > > > > xampl for Ruby -- > > <[7]http://rubyforge.org/projects/xampl/> > > > > > > > > > > > > > > > > _______________________________________________ > > Backgroundrb-devel mailing list > > [8]Backgroundrb-[7]devel at rubyforge.org > > [9]http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > References > > > > Visible links > > 1. mailto:[8]robert.bjarnason at gmail.com > > 2. mailto:[9]Backgroundrb-devel at rubyforge.org > > 3. [10]http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > 4. [11]http://www.recursive.ca/hutch/ > > 5. [12]http://www.recursive.ca/ > > 6. [13]http://www.raconteur.info/ > > 7. [14]http://rubyforge.org/projects/xampl/ > > 8. mailto: [15]Backgroundrb-devel at rubyforge.org > > 9. [16]http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > _______________________________________________ > > Backgroundrb-devel mailing list > > [17]Backgroundrb-devel at rubyforge.org > > [18]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 > | [19]skaar at waste.org > ---------------------------------------------------------------------- > > References > > Visible links > 1. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/24470 > 2. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/172652 > 3. mailto:skaar at waste.org > 4. mailto:masonhale at gmail.com > 5. http://gmail.com/ > 6. mailto:devel at rubyforge.org > 7. mailto:devel at rubyforge.org > 8. mailto:robert.bjarnason at gmail.com > 9. mailto:Backgroundrb-devel at rubyforge.org > 10. http://rubyforge.org/mailman/listinfo/backgroundrb-devel > 11. http://www.recursive.ca/hutch/ > 12. http://www.recursive.ca/ > 13. http://www.raconteur.info/ > 14. http://rubyforge.org/projects/xampl/ > 15. mailto:Backgroundrb-devel at rubyforge.org > 16. http://rubyforge.org/mailman/listinfo/backgroundrb-devel > 17. mailto:Backgroundrb-devel at rubyforge.org > 18. http://rubyforge.org/mailman/listinfo/backgroundrb-devel > 19. mailto:skaar at waste.org > _______________________________________________ > 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 tomasz at resourcestudio.nl Mon Jan 15 10:32:42 2007 From: tomasz at resourcestudio.nl (Tomasz Kaye) Date: Mon, 15 Jan 2007 16:32:42 +0100 Subject: [Backgroundrb-devel] Instantiating middleman and worker from inside a model? Message-ID: <16F52348-8BD0-465E-8ED0-86D48B0F2DFF@resourcestudio.nl> In short: how (if possible) would i go about arranging it so that i can instantiate a middleman and set a worker going from within a method in one of my models? or is this a weird thing to be wanting to do? ( My specific situation: I have an 'Image' model in my application. An actual image file associated with the model is being stored on amazons s3 system. I'd like to use a worker to handle each s3 operation (eg. deleting the image from s3). The Image model seems the neatest place to set the worker going but I'm a little stumped as to how i should modify my model to enable the instantiation of middleman within it. thanks in advance for any pointers! (apologies in advance if this message gets posted twice; i think my previous attempt didn't work) From mike.aizatsky at gmail.com Mon Jan 15 11:16:30 2007 From: mike.aizatsky at gmail.com (Mike Aizatsky) Date: Mon, 15 Jan 2007 19:16:30 +0300 Subject: [Backgroundrb-devel] Backgroundrb keeps spawning processes Message-ID: <49e1d9e50701150816i581527caib72a536785f37824@mail.gmail.com> Hi! I've just a created a really simple rails scheduled worker for backgroundrb to start playing with : class SessionCleanerWorker < BackgrounDRb::Worker::RailsBase def do_work(args) logger.info "SessionCleaner> started" CGI::Session::ActiveRecordStore::Session.destroy_all( ['updated_at done" end end SessionCleanerWorker.register It indeed works, and is being executed in the same process: 20070115-19:00:00 (6172) SessionCleaner> started 20070115-19:00:00 (6172) SessionCleaner> done 20070115-19:10:00 (6172) SessionCleaner> started 20070115-19:10:00 (6172) SessionCleaner> done However backgroundrb keeps spawning ruby processes for some strange reason without mentioning their ids in the log file: 20070115-18:50:00 (6171) Schedule triggered: # job=#, trigger=#, earliest=Mon Jan 15 18:50:00 +0300 2007, last=Mon Jan 15 18:50:00 +0300 2007> 20070115-18:50:00 (6171) Starting worker: session_cleaner_worker ceb1eb03562acb8cb9c866320084383d (session_cleaner_worker_ceb1eb03562acb8cb9c866320084383d) () 20070115-19:00:00 (6171) Schedule triggered: # job=#, trigger=#, earliest=Mon Jan 15 19:00:00 +0300 2007, last=Mon Jan 15 19:00:00 +0300 2007> 20070115-19:00:00 (6171) Starting worker: session_cleaner_worker bf18c891526f3d7d979ddb40642c0558 (session_cleaner_worker_bf18c891526f3d7d979ddb40642c0558) () ^[OC20070115-19:10:00 (6171) Schedule triggered: # job=#, trigger=#, earliest=Mon Jan 15 19:10:00 +0300 2007, last=Mon Jan 15 19:10:00 +0300 2007> 20070115-19:10:00 (6171) Starting worker: session_cleaner_worker ba173e9ecb22443bce084fac06545413 (session_cleaner_worker_ba173e9ecb22443bce084fac06545413) () and there're dozens of child ruby processes spawned from 6171 according to my activity monitor. Any idea how can this be traced down and/or fixed? -- Regards, Mike From masonhale at gmail.com Mon Jan 15 12:01:43 2007 From: masonhale at gmail.com (Mason Hale) Date: Mon, 15 Jan 2007 11:01:43 -0600 Subject: [Backgroundrb-devel] Backgroundrb keeps spawning processes In-Reply-To: <49e1d9e50701150816i581527caib72a536785f37824@mail.gmail.com> References: <49e1d9e50701150816i581527caib72a536785f37824@mail.gmail.com> Message-ID: <8bca3aa10701150901t121f3a71k8193bfc4418aceb3@mail.gmail.com> I've seen the same behavior before too. I found one needs to add a " self.delete" at the end of the do_work method, for the process to terminate after it's done doing its work. Mason On 1/15/07, Mike Aizatsky wrote: > > Hi! > > I've just a created a really simple rails scheduled worker for > backgroundrb to start playing with : > > class SessionCleanerWorker < BackgrounDRb::Worker::RailsBase > > def do_work(args) > logger.info "SessionCleaner> started" > > CGI::Session::ActiveRecordStore::Session.destroy_all( ['updated_at > LoginToken.destroy_expired > > logger.info "SessionCleaner> done" > end > > end > SessionCleanerWorker.register > > > It indeed works, and is being executed in the same process: > > 20070115-19:00:00 (6172) SessionCleaner> started > 20070115-19:00:00 (6172) SessionCleaner> done > 20070115-19:10:00 (6172) SessionCleaner> started > 20070115-19:10:00 (6172) SessionCleaner> done > > However backgroundrb keeps spawning ruby processes for some strange > reason without mentioning their ids in the log file: > > 20070115-18:50:00 (6171) Schedule triggered: # # > > job=#, > trigger=# 50], @month=1..12, @hour=0..23, @year=nil, @day=1..31, @cron_expr="0 > 0,10,20,30,40,50 * * * * *", @sec=[0], @wday=0..6>, earliest=Mon Jan > 15 18:50:00 +0300 2007, last=Mon Jan 15 18:50:00 +0300 2007> > 20070115-18:50:00 (6171) Starting worker: session_cleaner_worker > ceb1eb03562acb8cb9c866320084383d > (session_cleaner_worker_ceb1eb03562acb8cb9c866320084383d) () > 20070115-19:00:00 (6171) Schedule triggered: # # > > job=#, > trigger=# 50], @month=1..12, @hour=0..23, @year=nil, @day=1..31, @cron_expr="0 > 0,10,20,30,40,50 * * * * *", @sec=[0], @wday=0..6>, earliest=Mon Jan > 15 19:00:00 +0300 2007, last=Mon Jan 15 19:00:00 +0300 2007> > 20070115-19:00:00 (6171) Starting worker: session_cleaner_worker > bf18c891526f3d7d979ddb40642c0558 > (session_cleaner_worker_bf18c891526f3d7d979ddb40642c0558) () > ^[OC20070115-19:10:00 (6171) Schedule triggered: # # > > job=#, > trigger=# 50], @month=1..12, @hour=0..23, @year=nil, @day=1..31, @cron_expr="0 > 0,10,20,30,40,50 * * * * *", @sec=[0], @wday=0..6>, earliest=Mon Jan > 15 19:10:00 +0300 2007, last=Mon Jan 15 19:10:00 +0300 2007> > 20070115-19:10:00 (6171) Starting worker: session_cleaner_worker > ba173e9ecb22443bce084fac06545413 > (session_cleaner_worker_ba173e9ecb22443bce084fac06545413) () > > > and there're dozens of child ruby processes spawned from 6171 > according to my activity monitor. Any idea how can this be traced down > and/or fixed? > > -- > Regards, > Mike > _______________________________________________ > 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/20070115/528f3fcf/attachment.html From skaar at waste.org Mon Jan 15 13:37:41 2007 From: skaar at waste.org (skaar) Date: Mon, 15 Jan 2007 12:37:41 -0600 Subject: [Backgroundrb-devel] Backgroundrb keeps spawning processes In-Reply-To: <8bca3aa10701150901t121f3a71k8193bfc4418aceb3@mail.gmail.com> References: <49e1d9e50701150816i581527caib72a536785f37824@mail.gmail.com> <8bca3aa10701150901t121f3a71k8193bfc4418aceb3@mail.gmail.com> Message-ID: <20070115183741.GA18434@waste.org> Mason's observation is correct here. A worker spawns and stays around until told to terminate, so you will have to explicitly tell the worker to exit. An alternative strategy is, when you use the scheduler for example, is to let the worker live and repeatedly have the scheduler call a method on the same worker. You can do this by specifying the job_key - it will then use an existing worker or spawn a new worker. /skaar * Mason Hale (masonhale at gmail.com) [070115 10:57]: > I've seen the same behavior before too. I found one needs to add a > "self.delete" at the end of the do_work method, for the process to > terminate after it's done doing its work. > > Mason > > On 1/15/07, Mike Aizatsky <[1]mike.aizatsky at gmail.com> wrote: > > Hi! > > I've just a created a really simple rails scheduled worker for > backgroundrb to start playing with : > > class SessionCleanerWorker < BackgrounDRb::Worker::RailsBase > > def do_work(args) > [2]logger.info "SessionCleaner> started" > > CGI::Session::ActiveRecordStore::Session.destroy_all( ['updated_at > LoginToken.destroy_expired > > [3]logger.info "SessionCleaner> done" > end > > end > SessionCleanerWorker.register > > It indeed works, and is being executed in the same process: > > 20070115-19:00:00 (6172) SessionCleaner> started > 20070115-19:00:00 (6172) SessionCleaner> done > 20070115-19:10:00 (6172) SessionCleaner> started > 20070115-19:10:00 (6172) SessionCleaner> done > > However backgroundrb keeps spawning ruby processes for some strange > reason without mentioning their ids in the log file: > > 20070115-18:50:00 (6171) Schedule triggered: # # > job=#, > trigger=# 50], @month=1..12, @hour=0..23, @year=nil, @day=1..31, @cron_expr="0 > 0,10,20,30,40,50 * * * * *", @sec=[0], @wday=0..6>, earliest=Mon Jan > 15 18:50:00 +0300 2007, last=Mon Jan 15 18:50:00 +0300 2007> > 20070115-18:50:00 (6171) Starting worker: session_cleaner_worker > ceb1eb03562acb8cb9c866320084383d > (session_cleaner_worker_ceb1eb03562acb8cb9c866320084383d) () > 20070115-19:00:00 (6171) Schedule triggered: # # > job=#, > trigger=# 50], @month=1..12, @hour=0..23, @year=nil, @day=1..31, @cron_expr="0 > 0,10,20,30,40,50 * * * * *", @sec=[0], @wday=0..6>, earliest=Mon Jan > 15 19:00:00 +0300 2007, last=Mon Jan 15 19:00:00 +0300 2007> > 20070115-19:00:00 (6171) Starting worker: session_cleaner_worker > bf18c891526f3d7d979ddb40642c0558 > (session_cleaner_worker_bf18c891526f3d7d979ddb40642c0558) () > ^[OC20070115-19:10:00 (6171) Schedule triggered: # # > job=#, > trigger=# 50], @month=1..12, @hour=0..23, @year=nil, @day=1..31, @cron_expr="0 > 0,10,20,30,40,50 * * * * *", @sec=[0], @wday=0..6>, earliest=Mon Jan > 15 19:10:00 +0300 2007, last=Mon Jan 15 19:10:00 +0300 2007> > 20070115-19:10:00 (6171) Starting worker: session_cleaner_worker > ba173e9ecb22443bce084fac06545413 > (session_cleaner_worker_ba173e9ecb22443bce084fac06545413) () > > and there're dozens of child ruby processes spawned from 6171 > according to my activity monitor. Any idea how can this be traced down > and/or fixed? > > -- > Regards, > Mike > _______________________________________________ > Backgroundrb-devel mailing list > [4]Backgroundrb-devel at rubyforge.org > [5]http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > References > > Visible links > 1. mailto:mike.aizatsky at gmail.com > 2. http://logger.info/ > 3. http://logger.info/ > 4. mailto:Backgroundrb-devel at rubyforge.org > 5. http://rubyforge.org/mailman/listinfo/backgroundrb-devel > _______________________________________________ > 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 joshuabates at gmail.com Mon Jan 15 13:51:58 2007 From: joshuabates at gmail.com (Joshua Bates) Date: Mon, 15 Jan 2007 11:51:58 -0700 Subject: [Backgroundrb-devel] Instantiating middleman and worker from inside a model? In-Reply-To: <16F52348-8BD0-465E-8ED0-86D48B0F2DFF@resourcestudio.nl> References: <16F52348-8BD0-465E-8ED0-86D48B0F2DFF@resourcestudio.nl> Message-ID: Just call work_thread on the worker. Something like.... def save_to_s3 worker.work_thread(:method => :save, :args => [args]) end def worker @worker ||= MiddleMan.worker(:s3) end If you need to pass the whole model to the worker, make sure to add include DRbUndumped in your model. On 1/15/07, Tomasz Kaye wrote: > > In short: how (if possible) would i go about arranging it so that i > can instantiate a middleman and set a worker going from within a > method in one of my models? or is this a weird thing to be wanting to > do? ( > > My specific situation: I have an 'Image' model in my application. An > actual image file associated with the model is being stored on > amazons s3 system. I'd like to use a worker to handle each s3 > operation (eg. deleting the image from s3). The Image model seems the > neatest place to set the worker going but I'm a little stumped as to > how i should modify my model to enable the instantiation of middleman > within it. > > thanks in advance for any pointers! > > (apologies in advance if this message gets posted twice; i think my > previous attempt didn't work) > _______________________________________________ > 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/20070115/8c04f408/attachment.html From tomasz at resourcestudio.nl Tue Jan 16 09:11:36 2007 From: tomasz at resourcestudio.nl (Tomasz Kaye) Date: Tue, 16 Jan 2007 15:11:36 +0100 Subject: [Backgroundrb-devel] Instantiating middleman and worker from inside a model? In-Reply-To: References: <16F52348-8BD0-465E-8ED0-86D48B0F2DFF@resourcestudio.nl> Message-ID: <8ADB9FF9-0FC9-4E4E-8208-A4CC0E998E97@resourcestudio.nl> Thanks joshua, i thought i had tried this before but evidently i had something wrong, it's working fine now :) On Jan 15, 2007, at 7:51 PM, Joshua Bates wrote: > Just call work_thread on the worker. > Something like.... > > def save_to_s3 > worker.work_thread(:method => :save, :args => [args]) > end > > def worker > @worker ||= MiddleMan.worker(:s3) > end > > If you need to pass the whole model to the worker, make sure to add > include DRbUndumped in your model. > > On 1/15/07, Tomasz Kaye < tomasz at resourcestudio.nl> wrote: > In short: how (if possible) would i go about arranging it so that i > can instantiate a middleman and set a worker going from within a > method in one of my models? or is this a weird thing to be wanting to > do? ( > > My specific situation: I have an 'Image' model in my application. An > actual image file associated with the model is being stored on > amazons s3 system. I'd like to use a worker to handle each s3 > operation (eg. deleting the image from s3). The Image model seems the > neatest place to set the worker going but I'm a little stumped as to > how i should modify my model to enable the instantiation of middleman > within it. > > thanks in advance for any pointers! > > (apologies in advance if this message gets posted twice; i think my > previous attempt didn't work) > _______________________________________________ > 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/20070116/c006ebc7/attachment.html From jrobbins at cmj.com Tue Jan 16 10:34:13 2007 From: jrobbins at cmj.com (Jacob Robbins) Date: Tue, 16 Jan 2007 10:34:13 -0500 Subject: [Backgroundrb-devel] disable trigger logging in production Message-ID: <45ACF075.20600@cmj.com> i setup a trigger with an interval of 3 seconds, after a week in production the backgroundrb server log grew to 50 gigs from logging the execution of the trigger event. is there a way to disable the logging of that trigger event (or all of them) in production mode? --jacob From tomasz at resourcestudio.nl Tue Jan 16 11:43:50 2007 From: tomasz at resourcestudio.nl (Tomasz Kaye) Date: Tue, 16 Jan 2007 17:43:50 +0100 Subject: [Backgroundrb-devel] Instantiating middleman and worker from inside a model? In-Reply-To: References: <16F52348-8BD0-465E-8ED0-86D48B0F2DFF@resourcestudio.nl> Message-ID: <397F59F5-531E-4C91-B84D-5E8ABB865245@resourcestudio.nl> I spoke too soon, i'm still stuck with the same problem (sorry). Perhaps if i show how my model looks it'll be obvious what i'm doing wrong; class Image < ActiveRecord::Base def destroy s3delete super end def s3delete) MiddleMan.new_worker( :class => :s3_worker ) end end When i call destroy on an image model I'm getting the error: "NameError (uninitialized constant S3Worker):" . which is to be expected i suppose. How should i make S3Worker visible in this scope? thanks again. On Jan 15, 2007, at 7:51 PM, Joshua Bates wrote: > Just call work_thread on the worker. > Something like.... > > def save_to_s3 > worker.work_thread(:method => :save, :args => [args]) > end > > def worker > @worker ||= MiddleMan.worker(:s3) > end > > If you need to pass the whole model to the worker, make sure to add > include DRbUndumped in your model. > > On 1/15/07, Tomasz Kaye < tomasz at resourcestudio.nl> wrote: > In short: how (if possible) would i go about arranging it so that i > can instantiate a middleman and set a worker going from within a > method in one of my models? or is this a weird thing to be wanting to > do? ( > > My specific situation: I have an 'Image' model in my application. An > actual image file associated with the model is being stored on > amazons s3 system. I'd like to use a worker to handle each s3 > operation (eg. deleting the image from s3). The Image model seems the > neatest place to set the worker going but I'm a little stumped as to > how i should modify my model to enable the instantiation of middleman > within it. > > thanks in advance for any pointers! > > (apologies in advance if this message gets posted twice; i think my > previous attempt didn't work) > _______________________________________________ > 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/20070116/67b95e18/attachment.html From jrobbins at cmj.com Tue Jan 16 11:58:08 2007 From: jrobbins at cmj.com (Jacob Robbins) Date: Tue, 16 Jan 2007 11:58:08 -0500 Subject: [Backgroundrb-devel] Instantiating middleman and worker from inside a model? In-Reply-To: <397F59F5-531E-4C91-B84D-5E8ABB865245@resourcestudio.nl> References: <16F52348-8BD0-465E-8ED0-86D48B0F2DFF@resourcestudio.nl> <397F59F5-531E-4C91-B84D-5E8ABB865245@resourcestudio.nl> Message-ID: <45AD0420.1090207@cmj.com> as i understand it the S3Worker class does not need to be visible in the scope of the Image model. Only the MiddleMan class needs to be visible. You pass the :s3_worker symbol to the MiddleMan class and it uses that symbol to find the correct class on the other side of the drb connection (ie in the backgroundrb_server process, not here in the rails process). So i suggest going through a laundry list of different situations to see if this works anywhere in your code. -is that erroneous parentheses in "def s3delete)" only in your email? -can you call worker(:class => s3_worker) from the backgroundrb console? -try making a different method for the image class does nothing but instantiate an s3_worker and calling it in the rails console. -double check the class code for S3Worker to make sure the symbol :s3_worker will clearly resolve to both the class name and the file name. -try removing the 3 from the class name; it's not supposed to be a problem because it's not the first character of the name but i feel like i've had a problem with numbers in class names before. --jacob Tomasz Kaye wrote: > I spoke too soon, i'm still stuck with the same problem (sorry). Perhaps > if i show how my model looks it'll be obvious what i'm doing wrong; > > class Image < ActiveRecord::Base > > def destroy > s3delete > super > end > > def s3delete) > MiddleMan.new_worker( > :class => :s3_worker > ) > end > > end > > When i call destroy on an image model I'm getting the error: "NameError > (uninitialized constant S3Worker):" . which is to be expected i suppose. > How should i make S3Worker visible in this scope? > > thanks again. > > On Jan 15, 2007, at 7:51 PM, Joshua Bates wrote: > >> Just call work_thread on the worker. >> Something like.... >> >> def save_to_s3 >> worker.work_thread(:method => :save, :args => [args]) >> end >> >> def worker >> @worker ||= MiddleMan.worker(:s3) >> end >> >> If you need to pass the whole model to the worker, make sure to add >> include DRbUndumped in your model. >> >> On 1/15/07, *Tomasz Kaye* < tomasz at resourcestudio.nl >> > wrote: >> >> In short: how (if possible) would i go about arranging it so that i >> can instantiate a middleman and set a worker going from within a >> method in one of my models? or is this a weird thing to be wanting to >> do? ( >> >> My specific situation: I have an 'Image' model in my application. An >> actual image file associated with the model is being stored on >> amazons s3 system. I'd like to use a worker to handle each s3 >> operation (eg. deleting the image from s3). The Image model seems the >> neatest place to set the worker going but I'm a little stumped as to >> how i should modify my model to enable the instantiation of middleman >> within it. >> >> thanks in advance for any pointers! >> >> (apologies in advance if this message gets posted twice; i think my >> previous attempt didn't work) >> _______________________________________________ >> 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 From skaar at waste.org Tue Jan 16 12:08:42 2007 From: skaar at waste.org (skaar) Date: Tue, 16 Jan 2007 11:08:42 -0600 Subject: [Backgroundrb-devel] Instantiating middleman and worker from inside a model? In-Reply-To: <397F59F5-531E-4C91-B84D-5E8ABB865245@resourcestudio.nl> References: <16F52348-8BD0-465E-8ED0-86D48B0F2DFF@resourcestudio.nl> <397F59F5-531E-4C91-B84D-5E8ABB865245@resourcestudio.nl> Message-ID: <20070116170842.GC19689@waste.org> give: MiddleMan.instance.new_worker :class => :s3_worker a try * Tomasz Kaye (tomasz at resourcestudio.nl) [070116 10:37]: > I spoke too soon, i'm still stuck with the same problem (sorry). Perhaps > if i show how my model looks it'll be obvious what i'm doing wrong; > class Image < ActiveRecord::Base > > def destroy > s3delete > super > end > def s3delete) > MiddleMan.new_worker( > :class => :s3_worker > ) > end > end > When i call destroy on an image model I'm getting the error: "NameError > (uninitialized constant S3Worker):" . which is to be expected i suppose. > How should i make S3Worker visible in this scope? > thanks again. > On Jan 15, 2007, at 7:51 PM, Joshua Bates wrote: > > Just call work_thread on the worker. > Something like.... > > def save_to_s3 > worker.work_thread(:method => :save, :args => [args]) > end > > def worker > @worker ||= MiddleMan.worker(:s3) > end > > If you need to pass the whole model to the worker, make sure to add > include DRbUndumped in your model. > > On 1/15/07, Tomasz Kaye < [1]tomasz at resourcestudio.nl> wrote: > > In short: how (if possible) would i go about arranging it so that i > can instantiate a middleman and set a worker going from within a > method in one of my models? or is this a weird thing to be wanting to > do? ( > > My specific situation: I have an 'Image' model in my application. An > actual image file associated with the model is being stored on > amazons s3 system. I'd like to use a worker to handle each s3 > operation (eg. deleting the image from s3). The Image model seems the > neatest place to set the worker going but I'm a little stumped as to > how i should modify my model to enable the instantiation of middleman > within it. > > thanks in advance for any pointers! > > (apologies in advance if this message gets posted twice; i think my > previous attempt didn't work) > _______________________________________________ > Backgroundrb-devel mailing list > [2]Backgroundrb-devel at rubyforge.org > [3]http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > References > > Visible links > 1. mailto:tomasz at resourcestudio.nl > 2. mailto:Backgroundrb-devel at rubyforge.org > 3. http://rubyforge.org/mailman/listinfo/backgroundrb-devel > _______________________________________________ > 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 robert.bjarnason at gmail.com Tue Jan 16 12:59:19 2007 From: robert.bjarnason at gmail.com (Robert Bjarnason) Date: Tue, 16 Jan 2007 17:59:19 +0000 Subject: [Backgroundrb-devel] Load balancing In-Reply-To: <20070112000650.GB18716@waste.org> References: <45A6AF13.3070100@gmail.com> <36F895E0-FDD9-49D8-854F-7E9E750E4ACF@gmail.com> <45A6C1B9.3050007@gmail.com> <20070112000650.GB18716@waste.org> Message-ID: <45AD1277.5040703@gmail.com> Hi, FYI: Here is how I ended up implemented the load-balancing for our sites: 1. Create an array of available backgroundrb servers that includes how many workers can be active simultaneously: BACKGROUNDRB_SERVERS = [ ["druby://video1:2223", 3], ["druby://video2:2223", 1] , ... ] 2. When a middleman is needed I iterate over the array, connect to each server until I find a backgroundrb server that has a free slot. 3. Use BackgrounDRb::MiddleManDRbObject.init(:uri => "#{server[0]}") to open the connection to the selected server 4. If no server is free then the client request is placed in a queue and the user is informed. 5. Use self.delete in workers running on the servers, taking that responsibility away from client initiated actions. 6. Use the database to store the progress to get around that results bug. Note: I tried the setup with ruby-1.8.5-p12 and it has a silent crash that was not detected by begin/rescue when running more than one process, everything still works fine with ruby-1.8.4. The only thing I haven't figured out yet is how I close the connection from the client, self.delete doesn't close the middleman connection from the server side. The symptom is an ever growing list of established connections between clients and servers. I couldn't find an API in the middleman to close the connection explicitly - I think it must be the opposite to "DRb.start_service" but can't find anything in the backgroundrb code that would do this. Any ideas? Thanks, Robert Bjarnason skaar wrote: > * Robert Bjarnason (robert.bjarnason at gmail.com) [070111 16:56]: > >> Hi Erik, >> >> Thanks for the pointer, I have used JavaSpaces in the past and really >> like this pattern. >> >> However, my workers are user initiated and trigger x264 and mp4box video >> encoding/editing processes and I'm planning to have a limit of 1-2 >> simulations backgroundrb processes running on each physical server. >> >> I have an entry in the database for each user initiated job, maybe I can >> add the IP of each backgroundrb server to that entry and do the >> load-balancing in Rails using the database? The question then is how do >> I dynamically change the backgroundrb server IP for each instantiated >> MiddleMan object? >> > > you can use BackgrounDRb::MiddleManDRbObject and instead of calling the > MiddleMan constant, use a regular object - actually it's a class method > which takes a DRb uri as it's argument - behaves just like the > MiddleMan. > > /skaar > > > >> Warm regards, >> Robert Bjarnason >> >> ps. here are links to the sites that are currently using >> backgroundrb-2.1 more or less successfully in production mode: >> http://store.longwayround.com/ >> http://store.missingface.com/ >> http://store.racetodakar.com/ >> http://store.murderormutiny.com/ >> >> Erik Morton wrote: >> >>> We chose to bypass MiddleMan and place our requests for workers into a >>> queue. This way we can create an arbitrary number of workers that loop >>> and ask the queue for work. The Mongrels have no need to know the >>> location or number of workers. You will of course need another >>> strategy to get progress/results from the workers. >>> >>> On Jan 11, 2007, at 4:41 PM, Robert Bjarnason wrote: >>> >>> >>>> Hi, >>>> >>>> Can somebody point me in the right direction about what approach would >>>> be best to load-balance between two or more physical servers running >>>> backgroundrb while using BackgrounDRb::Worker::RailsBase with mongrel? >>>> >>>> Thanks, >>>> Robert Bjarnason >>>> >>>> _______________________________________________ >>>> 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 >> > > From robert.bjarnason at gmail.com Fri Jan 19 06:32:04 2007 From: robert.bjarnason at gmail.com (Robert Bjarnason) Date: Fri, 19 Jan 2007 11:32:04 +0000 Subject: [Backgroundrb-devel] Stopping DRb after using BackgrounDRb::MiddleManDRbObject.init Message-ID: <45B0AC34.5040004@gmail.com> Hi, I'm having a problem where connections started through BackgrounDRb::MiddleManDRbObject.init are not stopped, resulting in an ever growing established connections between my Mongrels and remote backgroundrbs I added DRb.stop_service to my code executed after requests that init MiddleManDRbObjects but that does not help. Any ideas? Thanks, Robert Bjarnason From michael.dauria at gmail.com Fri Jan 19 10:31:55 2007 From: michael.dauria at gmail.com (Michael D'Auria) Date: Fri, 19 Jan 2007 10:31:55 -0500 Subject: [Backgroundrb-devel] Stopping DRb after using BackgrounDRb::MiddleManDRbObject.init In-Reply-To: <45B0AC34.5040004@gmail.com> References: <45B0AC34.5040004@gmail.com> Message-ID: <1907e2ca0701190731j548a9e05sfbd6a70e303d8c83@mail.gmail.com> You need to clean up your workers yourself, so toss in a self.delete inside of the do_work method to have the worker clean up after itself or you can perform a delete on the worker on the outside using it's id. .: Michael :. On 1/19/07, Robert Bjarnason wrote: > > Hi, > > I'm having a problem where connections started through > BackgrounDRb::MiddleManDRbObject.init are not stopped, resulting in an > ever growing established connections between my Mongrels and remote > backgroundrbs > > I added DRb.stop_service to my code executed after requests that init > MiddleManDRbObjects but that does not help. > > Any ideas? > > Thanks, > Robert Bjarnason > > _______________________________________________ > 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/20070119/1f89d752/attachment.html From jrobbins at cmj.com Fri Jan 19 11:15:11 2007 From: jrobbins at cmj.com (Jacob Robbins) Date: Fri, 19 Jan 2007 11:15:11 -0500 Subject: [Backgroundrb-devel] Stopping DRb after using BackgrounDRb::MiddleManDRbObject.init In-Reply-To: <1907e2ca0701190731j548a9e05sfbd6a70e303d8c83@mail.gmail.com> References: <45B0AC34.5040004@gmail.com> <1907e2ca0701190731j548a9e05sfbd6a70e303d8c83@mail.gmail.com> Message-ID: <45B0EE8F.4060305@cmj.com> Robert, Is there more than one drb connection from each mongrel? I would think that each rails app would have one drb connection to each of the backgroundrb servers that it has accessed. I'm not quite understanding what the problem is, is it that you have N mongrels and M backgroundrb serves and it's too much to have N*M drb connections? Or is it that each mongrel is constantly making more new drb connections instead of reusing the existing ones? -Jacob Michael D'Auria wrote: > You need to clean up your workers yourself, so toss in a self.delete > inside of the do_work method to have the worker clean up after itself or > you can perform a delete on the worker on the outside using it's id. > > .: Michael :. > > > On 1/19/07, *Robert Bjarnason* > wrote: > > Hi, > > I'm having a problem where connections started through > BackgrounDRb::MiddleManDRbObject.init are not stopped, resulting in an > ever growing established connections between my Mongrels and remote > backgroundrbs > > I added DRb.stop_service to my code executed after requests that init > MiddleManDRbObjects but that does not help. > > Any ideas? > > Thanks, > Robert Bjarnason > > _______________________________________________ > 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 From robert.bjarnason at gmail.com Fri Jan 19 18:08:29 2007 From: robert.bjarnason at gmail.com (Robert Bjarnason) Date: Fri, 19 Jan 2007 23:08:29 +0000 Subject: [Backgroundrb-devel] Stopping DRb after using BackgrounDRb::MiddleManDRbObject.init In-Reply-To: <45B0EE8F.4060305@cmj.com> References: <45B0AC34.5040004@gmail.com> <1907e2ca0701190731j548a9e05sfbd6a70e303d8c83@mail.gmail.com> <45B0EE8F.4060305@cmj.com> Message-ID: <45B14F6D.7030300@gmail.com> Hi Jacob, Each mongrel is constantly making new drb connections instead of reusing or closing existing ones. Having N*M drb connections would not be a problem. Thanks, Robert Jacob Robbins wrote: > Robert, > Is there more than one drb connection from each mongrel? I would > think that each rails app would have one drb connection to each of the > backgroundrb servers that it has accessed. > > I'm not quite understanding what the problem is, is it that you have > N mongrels and M backgroundrb serves and it's too much to have N*M drb > connections? Or is it that each mongrel is constantly making more new > drb connections instead of reusing the existing ones? > > -Jacob > > > > Michael D'Auria wrote: > >> You need to clean up your workers yourself, so toss in a self.delete >> inside of the do_work method to have the worker clean up after itself or >> you can perform a delete on the worker on the outside using it's id. >> >> .: Michael :. >> >> >> On 1/19/07, *Robert Bjarnason* > > wrote: >> >> Hi, >> >> I'm having a problem where connections started through >> BackgrounDRb::MiddleManDRbObject.init are not stopped, resulting in an >> ever growing established connections between my Mongrels and remote >> backgroundrbs >> >> I added DRb.stop_service to my code executed after requests that init >> MiddleManDRbObjects but that does not help. >> >> Any ideas? >> >> Thanks, >> Robert Bjarnason >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > From ezmobius at gmail.com Fri Jan 19 18:18:36 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Fri, 19 Jan 2007 15:18:36 -0800 Subject: [Backgroundrb-devel] Stopping DRb after using BackgrounDRb::MiddleManDRbObject.init In-Reply-To: <45B14F6D.7030300@gmail.com> References: <45B0AC34.5040004@gmail.com> <1907e2ca0701190731j548a9e05sfbd6a70e303d8c83@mail.gmail.com> <45B0EE8F.4060305@cmj.com> <45B14F6D.7030300@gmail.com> Message-ID: <377A82D2-DAB9-4999-B2A0-0BCD006AB925@gmail.com> Robert- Is there some reason that you are calling BackgrounDRb::MiddleManDRbObject.init directly? You should let the BackgrounDRb::MiddleManRailsProxy take care of that. If you run it the normal way then each mongrel will only make one connection to the drb server. If you keep calling BackgrounDRb::MiddleManDRbObject.init you are going to keep making more connections. -Ezra On Jan 19, 2007, at 3:08 PM, Robert Bjarnason wrote: > Hi Jacob, > > Each mongrel is constantly making new drb connections instead of > reusing > or closing existing ones. Having N*M drb connections would not be a > problem. > > Thanks, > Robert > > Jacob Robbins wrote: >> Robert, >> Is there more than one drb connection from each mongrel? I would >> think that each rails app would have one drb connection to each of >> the >> backgroundrb servers that it has accessed. >> >> I'm not quite understanding what the problem is, is it that you >> have >> N mongrels and M backgroundrb serves and it's too much to have N*M >> drb >> connections? Or is it that each mongrel is constantly making more new >> drb connections instead of reusing the existing ones? >> >> -Jacob >> >> >> >> Michael D'Auria wrote: >> >>> You need to clean up your workers yourself, so toss in a self.delete >>> inside of the do_work method to have the worker clean up after >>> itself or >>> you can perform a delete on the worker on the outside using it's id. >>> >>> .: Michael :. >>> >>> >>> On 1/19/07, *Robert Bjarnason* >> > wrote: >>> >>> Hi, >>> >>> I'm having a problem where connections started through >>> BackgrounDRb::MiddleManDRbObject.init are not stopped, >>> resulting in an >>> ever growing established connections between my Mongrels and >>> remote >>> backgroundrbs >>> >>> I added DRb.stop_service to my code executed after requests >>> that init >>> MiddleManDRbObjects but that does not help. >>> >>> Any ideas? >>> >>> Thanks, >>> Robert Bjarnason >>> >>> _______________________________________________ >>> 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 >>> >> >> _______________________________________________ >> 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 robert.bjarnason at gmail.com Fri Jan 19 18:37:33 2007 From: robert.bjarnason at gmail.com (Robert Bjarnason) Date: Fri, 19 Jan 2007 23:37:33 +0000 Subject: [Backgroundrb-devel] Stopping DRb after using BackgrounDRb::MiddleManDRbObject.init In-Reply-To: <377A82D2-DAB9-4999-B2A0-0BCD006AB925@gmail.com> References: <45B0AC34.5040004@gmail.com> <1907e2ca0701190731j548a9e05sfbd6a70e303d8c83@mail.gmail.com> <45B0EE8F.4060305@cmj.com> <45B14F6D.7030300@gmail.com> <377A82D2-DAB9-4999-B2A0-0BCD006AB925@gmail.com> Message-ID: <45B1563D.8070100@gmail.com> Hi Ezra, I would like to control which uri is used to start the DRb connection for Rails based load-balancing purposes from multiple mongrels connecting to multiple backgroundrbs running on several boxes. I don't see how I could BackgrounDRb::MiddleManRailsProxy for this purpose. Any ideas? Thanks, Robert Ezra Zygmuntowicz wrote: > > Robert- > > Is there some reason that you are calling > BackgrounDRb::MiddleManDRbObject.init directly? You should let the > BackgrounDRb::MiddleManRailsProxy take care of that. If you run it the > normal way then each mongrel will only make one connection to the drb > server. If you keep calling BackgrounDRb::MiddleManDRbObject.init > you are going to keep making more connections. > > > -Ezra > > On Jan 19, 2007, at 3:08 PM, Robert Bjarnason wrote: > >> Hi Jacob, >> >> Each mongrel is constantly making new drb connections instead of reusing >> or closing existing ones. Having N*M drb connections would not be a >> problem. >> >> Thanks, >> Robert >> >> Jacob Robbins wrote: >>> Robert, >>> Is there more than one drb connection from each mongrel? I would >>> think that each rails app would have one drb connection to each of the >>> backgroundrb servers that it has accessed. >>> >>> I'm not quite understanding what the problem is, is it that you have >>> N mongrels and M backgroundrb serves and it's too much to have N*M drb >>> connections? Or is it that each mongrel is constantly making more new >>> drb connections instead of reusing the existing ones? >>> >>> -Jacob >>> >>> >>> >>> Michael D'Auria wrote: >>> >>>> You need to clean up your workers yourself, so toss in a self.delete >>>> inside of the do_work method to have the worker clean up after >>>> itself or >>>> you can perform a delete on the worker on the outside using it's id. >>>> >>>> .: Michael :. >>>> >>>> >>>> On 1/19/07, *Robert Bjarnason* >>> > wrote: >>>> >>>> Hi, >>>> >>>> I'm having a problem where connections started through >>>> BackgrounDRb::MiddleManDRbObject.init are not stopped, >>>> resulting in an >>>> ever growing established connections between my Mongrels and >>>> remote >>>> backgroundrbs >>>> >>>> I added DRb.stop_service to my code executed after requests >>>> that init >>>> MiddleManDRbObjects but that does not help. >>>> >>>> Any ideas? >>>> >>>> Thanks, >>>> Robert Bjarnason >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 ezmobius at gmail.com Fri Jan 19 19:01:19 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Fri, 19 Jan 2007 16:01:19 -0800 Subject: [Backgroundrb-devel] Stopping DRb after using BackgrounDRb::MiddleManDRbObject.init In-Reply-To: <45B1563D.8070100@gmail.com> References: <45B0AC34.5040004@gmail.com> <1907e2ca0701190731j548a9e05sfbd6a70e303d8c83@mail.gmail.com> <45B0EE8F.4060305@cmj.com> <45B14F6D.7030300@gmail.com> <377A82D2-DAB9-4999-B2A0-0BCD006AB925@gmail.com> <45B1563D.8070100@gmail.com> Message-ID: On Jan 19, 2007, at 3:37 PM, Robert Bjarnason wrote: > Hi Ezra, > > I would like to control which uri is used to start the DRb > connection for Rails based load-balancing purposes from multiple > mongrels connecting to multiple backgroundrbs running on several > boxes. I don't see how I could BackgrounDRb::MiddleManRailsProxy > for this purpose. Any ideas? > > Thanks, > Robert Robert- Ahh ok I see. Well maybe something like this(untested!) # start ---- require 'pathname' BACKGROUNDRB_ROOT = Pathname.new(RAILS_ROOT).realpath.to_s require 'backgroundrb' # Set up a MiddleMan for the BackgrounDRb server configured for this # particular instance of Rails. class BackgrounDRb::MiddleManProxyBalancer def self.init(server_pool={}) config = { :config => "#{BACKGROUNDRB_ROOT}/config/ backgroundrb.yml" } BackgrounDRb::Config.setup(config) @@proxy_members = {} server_pool.each {|num, drburi| @@proxy_members[num] = BackgrounDRb::MiddleManDRbObject.init (:uri => drburi) } return self end def self.[](key) @@proxy_members[key] end end server_pool = { 1 => "druby://localhost:22221", 2 => "druby://localhost:22222", 3 => "druby://10.0.0.123:22221", 4 => "druby://10.0.0.123:22221" } MiddleManPool = BackgrounDRb::MiddleManProxyBalancer.init(server_pool) # end ---- Then you would use the MiddleManPool in your rails apps instead of the normal rails proxy. You would have to key the middleman you want my the number in the server_pool. So it would look like this to use: session[:jobkey] = MiddleManPool[1].new_worker( :class => :someshit ) session[:otherjobkey] = MiddleManPool[2].new_worker( :class => :someshit ) worker = MiddleManPool[1].worker(session[:jobkey]) worker.results.to_hash worker = MiddleManPool[2].worker(session[: otherjobkey]) worker.results.to_hash This is just a sketch but I think you could take this and run with it. You would use the above to replace the BackgrounDRb::MiddleManRailsProxy in the lib dir of the plugin so that rails would load your new proxy instead of the old connection stuff. So this would make sure that every mongrel had a connection to every server in the server_pool. ANd you woudl just need to always use the number of which drb server you want from the pool. But it caches the connection so that each mongrel only gets one connection to every drb server. No new connection should be made after the thing boots because the connections are cached. Make sense? Please give this or something like this a shot and let us know how it goes for you. I am interested in adding something like this to the project. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From mike.aizatsky at gmail.com Mon Jan 22 08:26:14 2007 From: mike.aizatsky at gmail.com (Mike Aizatsky) Date: Mon, 22 Jan 2007 16:26:14 +0300 Subject: [Backgroundrb-devel] Yet Another Problem with BackgroundRB Message-ID: <49e1d9e50701220526g2af1b80dv25a369fec2c72a55@mail.gmail.com> Hi! My cron-based worker is being indeed invoked by backgroundRB at correct times. But... After several runs it can no longer find DB columns! The same query, which was running OK an hour ago starts to throw MySQL error about unkown column in where clause. If I restart backgroundrb it works for some time but stops working after several invocations. Has anyone epxerienced the similar beahviour? Are there any ideas of what can be wrong? Any hints? Anything I can check? -- Regards, Mike From masonhale at gmail.com Mon Jan 22 10:37:38 2007 From: masonhale at gmail.com (Mason Hale) Date: Mon, 22 Jan 2007 09:37:38 -0600 Subject: [Backgroundrb-devel] Yet Another Problem with BackgroundRB In-Reply-To: <49e1d9e50701220526g2af1b80dv25a369fec2c72a55@mail.gmail.com> References: <49e1d9e50701220526g2af1b80dv25a369fec2c72a55@mail.gmail.com> Message-ID: <8bca3aa10701220737p2f666a18rfc78ee5519da406a@mail.gmail.com> Hi Mike -- Can you please provide a stack trace or error message? If you run the same worker over and over, can you recreate the problem? Or does this happen after no worker is run for some extended period of time? (I'm guessing here that the db connection might be timing out) Do you know if the problem is triggered by a certain number of innvocations, or is it a lack of activity, or neither? Mason On 1/22/07, Mike Aizatsky wrote: > > Hi! > > My cron-based worker is being indeed invoked by backgroundRB at > correct times. But... After several runs it can no longer find DB > columns! The same query, which was running OK an hour ago starts to > throw MySQL error about unkown column in where clause. If I restart > backgroundrb it works for some time but stops working after several > invocations. > > Has anyone epxerienced the similar beahviour? Are there any ideas of > what can be wrong? Any hints? Anything I can check? > > -- > Regards, > Mike > _______________________________________________ > 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/20070122/e584312e/attachment.html From jrobbins at cmj.com Mon Jan 22 10:42:22 2007 From: jrobbins at cmj.com (Jacob Robbins) Date: Mon, 22 Jan 2007 10:42:22 -0500 Subject: [Backgroundrb-devel] Yet Another Problem with BackgroundRB In-Reply-To: <49e1d9e50701220526g2af1b80dv25a369fec2c72a55@mail.gmail.com> References: <49e1d9e50701220526g2af1b80dv25a369fec2c72a55@mail.gmail.com> Message-ID: <45B4DB5E.5050900@cmj.com> long running scripts lose connection to the mysql server if they don't have any activity for a while. the connection library is supposed to reconnect when this happens but in my experience it doesn't. i'm not sure if this is the problem you're hitting, but if so, one workaround is to have the script perform a simple query every 5 minutes. this ensures that the mysql server never closes the connection due. -Jacob Mike Aizatsky wrote: > Hi! > > My cron-based worker is being indeed invoked by backgroundRB at > correct times. But... After several runs it can no longer find DB > columns! The same query, which was running OK an hour ago starts to > throw MySQL error about unkown column in where clause. If I restart > backgroundrb it works for some time but stops working after several > invocations. > > Has anyone epxerienced the similar beahviour? Are there any ideas of > what can be wrong? Any hints? Anything I can check? > From mike.aizatsky at gmail.com Mon Jan 22 11:00:18 2007 From: mike.aizatsky at gmail.com (Mike Aizatsky) Date: Mon, 22 Jan 2007 19:00:18 +0300 Subject: [Backgroundrb-devel] Yet Another Problem with BackgroundRB In-Reply-To: <8bca3aa10701220737p2f666a18rfc78ee5519da406a@mail.gmail.com> References: <49e1d9e50701220526g2af1b80dv25a369fec2c72a55@mail.gmail.com> <8bca3aa10701220737p2f666a18rfc78ee5519da406a@mail.gmail.com> Message-ID: <49e1d9e50701220800l7ac5e987kc28cfaa2808eb9e2@mail.gmail.com> Mason, The stacktrace is at the end of the message. > If you run the same worker over and over, can you recreate the problem? > Or does this happen after no worker is run for some extended period of time? > (I'm guessing > here that the db connection might be timing out) I'm running my worker every 10 minutes. According to log files sometimes it takes just 3-4 executions to break. But I've also experienced a longer periods of successfull runs (3-4 hours). > > Do you know if the problem is triggered by a certain number of innvocations, > or is it a lack of activity, or neither? Nope, I don't. However it does look like something is wrong with connection. --------- 20070122-15:21:00 (22914) Mysql::Error: Unknown column 'drill_notification' in 'where clause': SELECT * FROM users WHERE (drill_notification = 1 AND drill_notification_last_send < '20070122' AND drill_notification_time < 44460 ) - (ActiveRecord::StatementInvalid)rs/abstract_adapter.rb:128:in `log'0070122-15:21:00 (22914) /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/connection_adapters/mysql_adapter.rb:243:in `execute'070122-15:21:00 (22914) /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/connection_adapters/mysql_adapter.rb:395:in `select'0070122-15:21:00 (22914) /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in `select_all'(22914) /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/base.rb:424:in `find_by_sql' 20070122-15:21:00 (22914) /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/base.rb:994:in `find_every' 20070122-15:21:00 (22914) /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/base.rb:415:in `find' 20070122-15:21:00 (22914) /u/apps/learnbyrote/releases/20070121210300/config/../app/models/user.rb:74:in `find_all_to_send_drill_reminder' 20070122-15:21:00 (22914) /u/apps/learnbyrote/releases/20070121210300/lib/workers/drill_reminder_worker.rb:10:in `do_work' 20070122-15:21:00 (22914) /u/apps/learnbyrote/releases/20070121210300/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:55:in `send' 20070122-15:21:00 (22914) /u/apps/learnbyrote/releases/20070121210300/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:55:in `work_thread'070122-15:21:00 (22914) /u/apps/learnbyrote/releases/20070121210300/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:69:in `call' 20070122-15:21:00 (22914) /u/apps/learnbyrote/releases/20070121210300/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:69:in `work_thread'070122-15:21:00 (22914) /u/apps/learnbyrote/releases/20070121210300/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:67:in `initialize'0070122-15:21:00 (22914) /u/apps/learnbyrote/releases/20070121210300/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:67:in `new' 20070122-15:21:00 (22914) /u/apps/learnbyrote/releases/20070121210300/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:67:in `work_thread'070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1555:in `__send__' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1555:in `perform_without_block' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1515:in `perform' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1585:in `loop' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1581:in `start' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1430:in `run' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1427:in `start' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1347:in `initialize' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1627:in `new' 20070122-15:21:00 (22914) /opt/local/lib/ruby/1.8/drb/drb.rb:1627:in `start_service' 20070122-15:21:00 (22914) /opt/local/lib/ruby/gems/1.8/gems/slave-1.2.0/lib/slave.rb:396:in `initialize' 20070122-15:21:00 (22914) /opt/local/lib/ruby/gems/1.8/gems/slave-1.2.0/lib/slave.rb:391:in `times' 20070122-15:21:00 (22914) /opt/local/lib/ruby/gems/1.8/gems/slave-1.2.0/lib/slave.rb:391:in `initialize' On 1/22/07, Mason Hale wrote: > Hi Mike -- > > Can you please provide a stack trace or error message? > > If you run the same worker over and over, can you recreate the problem? > Or does this happen after no worker is run for some extended period of time? > (I'm guessing > here that the db connection might be timing out) > > Do you know if the problem is triggered by a certain number of innvocations, > or is it a lack of activity, or neither? > > Mason > > > On 1/22/07, Mike Aizatsky wrote: > > > > Hi! > > > > My cron-based worker is being indeed invoked by backgroundRB at > > correct times. But... After several runs it can no longer find DB > > columns! The same query, which was running OK an hour ago starts to > > throw MySQL error about unkown column in where clause. If I restart > > backgroundrb it works for some time but stops working after several > > invocations. > > > > Has anyone epxerienced the similar beahviour? Are there any ideas of > > what can be wrong? Any hints? Anything I can check? > > > > -- > > Regards, > > Mike > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > -- Regards, Mike From mike.aizatsky at gmail.com Mon Jan 22 11:04:42 2007 From: mike.aizatsky at gmail.com (Mike Aizatsky) Date: Mon, 22 Jan 2007 19:04:42 +0300 Subject: [Backgroundrb-devel] Yet Another Problem with BackgroundRB In-Reply-To: <8bca3aa10701220737p2f666a18rfc78ee5519da406a@mail.gmail.com> References: <49e1d9e50701220526g2af1b80dv25a369fec2c72a55@mail.gmail.com> <8bca3aa10701220737p2f666a18rfc78ee5519da406a@mail.gmail.com> Message-ID: <49e1d9e50701220804s74e70f05t2746547a059c59ef@mail.gmail.com> Mason, I've just had an idea and it turned out to be true in my situation. It turned out, that after a while backgroundrb connects to my _development_ database instead of production one. I'm invoking backgroundrb with the following command: script/backgroundrb start -- -r production It looks like -r doesn't propagate nicely. On 1/22/07, Mason Hale wrote: > Hi Mike -- > > Can you please provide a stack trace or error message? > > If you run the same worker over and over, can you recreate the problem? > Or does this happen after no worker is run for some extended period of time? > (I'm guessing > here that the db connection might be timing out) > > Do you know if the problem is triggered by a certain number of innvocations, > or is it a lack of activity, or neither? > > Mason > > > On 1/22/07, Mike Aizatsky wrote: > > > > Hi! > > > > My cron-based worker is being indeed invoked by backgroundRB at > > correct times. But... After several runs it can no longer find DB > > columns! The same query, which was running OK an hour ago starts to > > throw MySQL error about unkown column in where clause. If I restart > > backgroundrb it works for some time but stops working after several > > invocations. > > > > Has anyone epxerienced the similar beahviour? Are there any ideas of > > what can be wrong? Any hints? Anything I can check? > > > > -- > > Regards, > > Mike > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > -- Regards, Mike From masonhale at gmail.com Mon Jan 22 11:09:11 2007 From: masonhale at gmail.com (Mason Hale) Date: Mon, 22 Jan 2007 10:09:11 -0600 Subject: [Backgroundrb-devel] Yet Another Problem with BackgroundRB In-Reply-To: <49e1d9e50701220804s74e70f05t2746547a059c59ef@mail.gmail.com> References: <49e1d9e50701220526g2af1b80dv25a369fec2c72a55@mail.gmail.com> <8bca3aa10701220737p2f666a18rfc78ee5519da406a@mail.gmail.com> <49e1d9e50701220804s74e70f05t2746547a059c59ef@mail.gmail.com> Message-ID: <8bca3aa10701220809n6a0a80b1q5865ae209087a923@mail.gmail.com> That sounds like a BackgroundRb bug. FWIW -- I've got a production backgroundrb app running smoothly, but I use the RAILS_ENV setting in the backgroundrb.yml to set it to a production environment. I do not use the -r setting. Mason On 1/22/07, Mike Aizatsky wrote: > > Mason, > > I've just had an idea and it turned out to be true in my situation. It > turned out, that after a while backgroundrb connects to my > _development_ database instead of production one. I'm invoking > backgroundrb with the following command: > > script/backgroundrb start -- -r production > > It looks like -r doesn't propagate nicely. > > On 1/22/07, Mason Hale wrote: > > Hi Mike -- > > > > Can you please provide a stack trace or error message? > > > > If you run the same worker over and over, can you recreate the problem? > > Or does this happen after no worker is run for some extended period of > time? > > (I'm guessing > > here that the db connection might be timing out) > > > > Do you know if the problem is triggered by a certain number of > innvocations, > > or is it a lack of activity, or neither? > > > > Mason > > > > > > On 1/22/07, Mike Aizatsky wrote: > > > > > > Hi! > > > > > > My cron-based worker is being indeed invoked by backgroundRB at > > > correct times. But... After several runs it can no longer find DB > > > columns! The same query, which was running OK an hour ago starts to > > > throw MySQL error about unkown column in where clause. If I restart > > > backgroundrb it works for some time but stops working after several > > > invocations. > > > > > > Has anyone epxerienced the similar beahviour? Are there any ideas of > > > what can be wrong? Any hints? Anything I can check? > > > > > > -- > > > Regards, > > > Mike > > > _______________________________________________ > > > Backgroundrb-devel mailing list > > > Backgroundrb-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > > > > > > -- > Regards, > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070122/0ddb110b/attachment-0001.html From swistak at expro.pl Mon Jan 22 08:24:26 2007 From: swistak at expro.pl (swistak at expro.pl) Date: Mon, 22 Jan 2007 13:24:26 GMT Subject: [Backgroundrb-devel] MiddleMan behavior Message-ID: i found some questions and answers on mailing lists but there is still a problem - when i want to create new worker from within a worker - ::BackgrounDRb::MiddleMan.new_worker(:class => :second_worker, :args => {:id=>2, :text=>"slave"}) works but when i want to get reference to that object: ::BackgrounDRb::MiddleMan.worker(@second) yields: NoMethodError: undefined method `worker' for BackgrounDRb::MiddleMan:Class from (drbunix:///tmp/backgroundrbunix_localhost_2999) (drbunix:///tmp/backgroundrb.8516/first_worker_c6824af92d0ae35bcbba75df4e282 b6f_0_0.158526073008825) /home/swistak/rails+backgroundrb/lib/workers/first_worker.rb:26:in `get_second_ref' from (irb):223 from :0 From skaar at waste.org Mon Jan 22 11:22:27 2007 From: skaar at waste.org (skaar) Date: Mon, 22 Jan 2007 10:22:27 -0600 Subject: [Backgroundrb-devel] MiddleMan behavior In-Reply-To: References: Message-ID: <20070122162227.GA22627@waste.org> > ::BackgrounDRb::MiddleMan.worker(@second) > > yields: > > NoMethodError: undefined method `worker' for BackgrounDRb::MiddleMan:Class > from (drbunix:///tmp/backgroundrbunix_localhost_2999) > (drbunix:///tmp/backgroundrb.8516/first_worker_c6824af92d0ae35bcbba75df4e282 > b6f_0_0.158526073008825) > /home/swistak/rails+backgroundrb/lib/workers/first_worker.rb:26:in > `get_second_ref' > from (irb):223 > from :0 This is kind of a legacy problem, given that we've used the MiddleMan constant on the Rails side to represent the MiddleMan _instance_ rather than the class. 'worker' is an instance method, so you would have to: MiddleMan.instance.worker(@second) /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 mike.aizatsky at gmail.com Mon Jan 22 12:07:32 2007 From: mike.aizatsky at gmail.com (Mike Aizatsky) Date: Mon, 22 Jan 2007 20:07:32 +0300 Subject: [Backgroundrb-devel] Yet Another Problem with BackgroundRB In-Reply-To: <8bca3aa10701220809n6a0a80b1q5865ae209087a923@mail.gmail.com> References: <49e1d9e50701220526g2af1b80dv25a369fec2c72a55@mail.gmail.com> <8bca3aa10701220737p2f666a18rfc78ee5519da406a@mail.gmail.com> <49e1d9e50701220804s74e70f05t2746547a059c59ef@mail.gmail.com> <8bca3aa10701220809n6a0a80b1q5865ae209087a923@mail.gmail.com> Message-ID: <49e1d9e50701220907w5d7fba7tb551716a9d270695@mail.gmail.com> Mason, How do you test your workers in development? On 1/22/07, Mason Hale wrote: > That sounds like a BackgroundRb bug. > > FWIW -- I've got a production backgroundrb app running smoothly, > but I use the RAILS_ENV setting in the backgroundrb.yml to > set it to a production environment. I do not use the -r setting. From swistak at expro.pl Mon Jan 22 07:59:17 2007 From: swistak at expro.pl (swistak at expro.pl) Date: Mon, 22 Jan 2007 12:59:17 GMT Subject: [Backgroundrb-devel] Strange behavior Message-ID: Ok two things that bug me 1) http://backgroundrb.devjavu.com/projects/backgroundrb/ticket/48 i thought i'll just post ticket link - but well - it's strange 2) when i switch base class from RailsBase to Base i can't access MiddleMan - i get error NameError: uninitialized constant MiddleMan from (drbunix:///tmp/backgroundrbunix_localhost_2999) (drbunix:///tmp/backgroundrb.8388/first_worker_30fe4904c2222fa80e54b58d587d7 bb0_0_0.446368947706132) /home/swistak/rails+backgroundrb/config/../vendor/rails/activerecord/lib/../ ../activesupport/lib/active_support/dependencies.rb:123:in `const_missing' from (drbunix:///tmp/backgroundrbunix_localhost_2999) (drbunix:///tmp/backgroundrb.8388/first_worker_30fe4904c2222fa80e54b58d587d7 bb0_0_0.446368947706132) /home/swistak/rails+backgroundrb/config/../vendor/rails/activerecord/lib/../ ../activesupport/lib/active_support/dependencies.rb:131:in `const_missing' from (drbunix:///tmp/backgroundrbunix_localhost_2999) (drbunix:///tmp/backgroundrb.8388/first_worker_30fe4904c2222fa80e54b58d587d7 bb0_0_0.446368947706132) /home/swistak/rails+backgroundrb/config/../vendor/rails/activerecord/lib/../ ../activesupport/lib/active_support/dependencies.rb:133:in `send' from (drbunix:///tmp/backgroundrbunix_localhost_2999) (drbunix:///tmp/backgroundrb.8388/first_worker_30fe4904c2222fa80e54b58d587d7 bb0_0_0.446368947706132) /home/swistak/rails+backgroundrb/config/../vendor/rails/activerecord/lib/../ ../activesupport/lib/active_support/dependencies.rb:133:in `const_missing' from (drbunix:///tmp/backgroundrbunix_localhost_2999) (drbunix:///tmp/backgroundrb.8388/first_worker_30fe4904c2222fa80e54b58d587d7 bb0_0_0.446368947706132) /home/swistak/rails+backgroundrb/lib/workers/first_worker.rb:10:in `new_second' from (irb):192 from :0 anyone have any idea why this happens ? From skaar at waste.org Mon Jan 22 13:20:14 2007 From: skaar at waste.org (skaar) Date: Mon, 22 Jan 2007 12:20:14 -0600 Subject: [Backgroundrb-devel] Strange behavior In-Reply-To: References: Message-ID: <20070122182014.GB22627@waste.org> * swistak at expro.pl (swistak at expro.pl) [070122 11:15]: > Ok two things that bug me > 1) http://backgroundrb.devjavu.com/projects/backgroundrb/ticket/48 > i thought i'll just post ticket link - but well - it's strange I will have to look at this. I've seen that there's been a number of postings on creating workers from other workers, which is something that I've not myself done all that much. > > 2) when i switch base class from RailsBase to Base i can't access MiddleMan > - i get error could you try BackgrounDRb::MiddeMan ? /skaar > > > NameError: uninitialized constant MiddleMan > from (drbunix:///tmp/backgroundrbunix_localhost_2999) > (drbunix:///tmp/backgroundrb.8388/first_worker_30fe4904c2222fa80e54b58d587d7 > bb0_0_0.446368947706132) > /home/swistak/rails+backgroundrb/config/../vendor/rails/activerecord/lib/../ > ../activesupport/lib/active_support/dependencies.rb:123:in `const_missing' > from (drbunix:///tmp/backgroundrbunix_localhost_2999) > (drbunix:///tmp/backgroundrb.8388/first_worker_30fe4904c2222fa80e54b58d587d7 > bb0_0_0.446368947706132) > /home/swistak/rails+backgroundrb/config/../vendor/rails/activerecord/lib/../ > ../activesupport/lib/active_support/dependencies.rb:131:in `const_missing' > from (drbunix:///tmp/backgroundrbunix_localhost_2999) > (drbunix:///tmp/backgroundrb.8388/first_worker_30fe4904c2222fa80e54b58d587d7 > bb0_0_0.446368947706132) > /home/swistak/rails+backgroundrb/config/../vendor/rails/activerecord/lib/../ > ../activesupport/lib/active_support/dependencies.rb:133:in `send' > from (drbunix:///tmp/backgroundrbunix_localhost_2999) > (drbunix:///tmp/backgroundrb.8388/first_worker_30fe4904c2222fa80e54b58d587d7 > bb0_0_0.446368947706132) > /home/swistak/rails+backgroundrb/config/../vendor/rails/activerecord/lib/../ > ../activesupport/lib/active_support/dependencies.rb:133:in `const_missing' > from (drbunix:///tmp/backgroundrbunix_localhost_2999) > (drbunix:///tmp/backgroundrb.8388/first_worker_30fe4904c2222fa80e54b58d587d7 > bb0_0_0.446368947706132) > /home/swistak/rails+backgroundrb/lib/workers/first_worker.rb:10:in > `new_second' > from (irb):192 > from :0 > > > anyone have any idea why this happens ? > _______________________________________________ > 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 masonhale at gmail.com Mon Jan 22 17:24:43 2007 From: masonhale at gmail.com (Mason Hale) Date: Mon, 22 Jan 2007 16:24:43 -0600 Subject: [Backgroundrb-devel] Yet Another Problem with BackgroundRB In-Reply-To: <49e1d9e50701220907w5d7fba7tb551716a9d270695@mail.gmail.com> References: <49e1d9e50701220526g2af1b80dv25a369fec2c72a55@mail.gmail.com> <8bca3aa10701220737p2f666a18rfc78ee5519da406a@mail.gmail.com> <49e1d9e50701220804s74e70f05t2746547a059c59ef@mail.gmail.com> <8bca3aa10701220809n6a0a80b1q5865ae209087a923@mail.gmail.com> <49e1d9e50701220907w5d7fba7tb551716a9d270695@mail.gmail.com> Message-ID: <8bca3aa10701221424u42d25298o196871638991f5a7@mail.gmail.com> I definitely see a lot of opportunity in improving the test support of backgroundrb. The tests I have written start a worker in the test using MiddleMan.new_worker and then check its results (stored in a database) externally. [Note: there are some issues with the ResultsWorker at present that make it unreliable as a means of checking the state of your worker processes, thus all state is stored in a database.] This has the advantage of testing the full stack in a real-world-ish scenario. It has the downside that it only works with relatively simple workers. Here's an example: == /test/unit/backgroundrb_test ============ require File.dirname(__FILE__) + '/../test_helper' class BackgroundrbTest < Test::Unit::TestCase def setup # start backgroundrb server `../../script/backgroundrb start` puts "starting backgroundrb server..." sleep 2 # give it time to startup end def teardown # stop backgroundrb server `../../script/backgroundrb stop` puts "backgroundrb server stopped" end def test_drb keys = [] 10.times do |i| key = MiddleMan.new_worker(:class => :example_worker) puts "Started process: #{key}" keys << key end keys.each_with_index do |k, i| puts "Checking #{k}" mm = MiddleMan[k] assert_not_nil mm, "checking job_key #{k} on iteration #{i}" puts "found job: #{mm}" mw = MiddleMan.worker(k) assert_not_nil mw, "checking job_key #{k} on iteration #{i}" puts "found worker: #{mw}" end end end ========================== This test just creates 10 workers and then makes sure they are reachable later via the generated job keys. The test could just as easily create a worker, sleep for a few seconds to let it do it's work, then check the database for the results. I have adopted a habit of writing dead-simple workers, where all work is done via an external class, either a model class or library that is loaded by the worker. I can then test these classes independently because they do not have a dependency on running within or being loaded by the backgroundrb_server. The worker should just extract the params it needs from the args passed to it, instantiate/load the object/class it needs to do it's work -- and then call a method on that object/class. These external objects can be tested normally. The tricky part is checking the results of a separate process. I use a database for as a medium for that now. I don't have a way to test a worker in the same process, although I'm sure that can be worked out. This setup is not ideal, and it won't work for everyone, but for now it's workable for me. Mason On 1/22/07, Mike Aizatsky wrote: > > Mason, > > How do you test your workers in development? > > On 1/22/07, Mason Hale wrote: > > That sounds like a BackgroundRb bug. > > > > FWIW -- I've got a production backgroundrb app running smoothly, > > but I use the RAILS_ENV setting in the backgroundrb.yml to > > set it to a production environment. I do not use the -r setting. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070122/24627658/attachment.html From swistak at expro.pl Mon Jan 22 17:37:46 2007 From: swistak at expro.pl (swistak at expro.pl) Date: Mon, 22 Jan 2007 22:37:46 GMT Subject: [Backgroundrb-devel] Creating workers from workers, calling functions Message-ID: Anyone have idea, what's the best way to run one workers from another, and call functions betwen them ? From tomasz at resourcestudio.nl Tue Jan 23 06:13:22 2007 From: tomasz at resourcestudio.nl (Tomasz Kaye) Date: Tue, 23 Jan 2007 12:13:22 +0100 Subject: [Backgroundrb-devel] Instantiating middleman and worker from inside a model? In-Reply-To: <20070116170842.GC19689@waste.org> References: <16F52348-8BD0-465E-8ED0-86D48B0F2DFF@resourcestudio.nl> <397F59F5-531E-4C91-B84D-5E8ABB865245@resourcestudio.nl> <20070116170842.GC19689@waste.org> Message-ID: <491C654B-FB14-4870-9FD6-F1574ACF8262@resourcestudio.nl> thats for all the suggestions and help! I think in the end it was a stray 'end' that was causing the errors, and i was looking for something more complicated. apologies for not checking my code more thoroughly! From tomasz at resourcestudio.nl Tue Jan 23 06:19:24 2007 From: tomasz at resourcestudio.nl (Tomasz Kaye) Date: Tue, 23 Jan 2007 12:19:24 +0100 Subject: [Backgroundrb-devel] Getting results from a dead worker. example? Message-ID: <1B16C983-1AF9-4DCD-8586-56925625517F@resourcestudio.nl> I'm having a little difficulty understanding how to retrieve results from deceased workers (from the documentation it seems that it is possible to do this). I pasted my simple test below. If anyone could point out what i should be doing differently i'd be very grateful. My test worker: class TestWorker < BackgrounDRb::Worker::RailsBase def do_work(args) results[:done_with_do_work] = true self.delete end end TestWorker.register My rake task: task :tester => :environment do k=MiddleMan.new_worker( :class => :test_worker ) sleep 1 # the worker will die during this pause # next line gives a nil object error puts "done_with_do_work=#{MiddleMan.worker(k).results [:done_with_do_work]||"not available"}" end From swistak at expro.pl Tue Jan 23 07:02:47 2007 From: swistak at expro.pl (swistak at expro.pl) Date: Tue, 23 Jan 2007 12:02:47 GMT Subject: [Backgroundrb-devel] Error while creating one worker from another Message-ID: for some strange reason this error occours when i create one worker from another BUT only when i derive worker class from Worker::Base instead or Worker::RailsBase - when change it back it works fine, child worker can have empty do_work, but this error still ocours Bad file descriptor (Errno::EBADF) /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:214:in `for_fd' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:214:in `close_unused_sockets_after_forking' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:138:in `each' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:138:in `send' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:138:in `method_missing' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:135:in `ex' /usr/lib/ruby/1.8/sync.rb:229:in `synchronize' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:135:in `ex' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:138:in `method_missing' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:211:in `close_unused_sockets_after_forking' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:204:in `catch' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:355:in `initialize' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/middleman.rb:210:in `new' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/middleman.rb:210:in `new_worker' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/thread_pool.rb:36:in `dispatch' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/thread_pool.rb:22:in `initialize' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/thread_pool.rb:22:in `new' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/thread_pool.rb:22:in `dispatch' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/middleman.rb:199:in `new_worker' /home/swistak/rails+backgroundrb/lib/workers/menager_worker.rb:47:in `new_mailman' /home/swistak/rails+backgroundrb/lib/workers/menager_worker.rb:34:in `do_work' /home/swistak/rails+backgroundrb/lib/workers/menager_worker.rb:30:in `times' /home/swistak/rails+backgroundrb/lib/workers/menager_worker.rb:30:in `do_work' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /home/swistak/rails+backgroundrb/lib/workers/menager_worker.rb:29:in `do_work' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/worker.rb:55:in `send' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/worker.rb:55:in `work_thread' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/worker.rb:69:in `call' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/worker.rb:69:in `work_thread' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/worker.rb:67:in `initialize' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/worker.rb:67:in `new' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/worker.rb:67:in `work_thread' /usr/lib/ruby/1.8/drb/drb.rb:1555:in `__send__' /usr/lib/ruby/1.8/drb/drb.rb:1555:in `perform_without_block' /usr/lib/ruby/1.8/drb/drb.rb:1515:in `perform' /usr/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1585:in `loop' /usr/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1581:in `start' /usr/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1430:in `run' /usr/lib/ruby/1.8/drb/drb.rb:1427:in `start' /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' /usr/lib/ruby/1.8/drb/drb.rb:1347:in `initialize' /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' /usr/lib/ruby/1.8/drb/drb.rb:1627:in `start_service' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:396:in `initialize' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:391:in `times' /var/lib/gems/1.8/gems/slave-1.2.0/lib/slave.rb:391:in `initialize' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/middleman.rb:210:in `new' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/middleman.rb:210:in `new_worker' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/thread_pool.rb:36:in `dispatch' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/thread_pool.rb:22:in `initialize' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/thread_pool.rb:22:in `new' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/thread_pool.rb:22:in `dispatch' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb/middleman.rb:199:in `new_worker' /usr/lib/ruby/1.8/drb/drb.rb:1555:in `__send__' /usr/lib/ruby/1.8/drb/drb.rb:1555:in `perform_without_block' /usr/lib/ruby/1.8/drb/drb.rb:1515:in `perform' /usr/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1585:in `loop' /usr/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1581:in `start' /usr/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop' /usr/lib/ruby/1.8/drb/drb.rb:1430:in `run' /usr/lib/ruby/1.8/drb/drb.rb:1427:in `start' /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' /usr/lib/ruby/1.8/drb/drb.rb:1347:in `initialize' /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' /usr/lib/ruby/1.8/drb/drb.rb:1627:in `start_service' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb_server.rb:315:in `run' /var/lib/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in `call' /var/lib/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in `start_proc' /var/lib/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:196:in `call' /var/lib/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:196:in `start_proc' /var/lib/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:226:in `start' /var/lib/gems/1.8/gems/daemons-1.0.3/lib/daemons/controller.rb:72:in `run' /var/lib/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in `run_proc' /var/lib/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in `call' /var/lib/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in `catch_exceptions' /var/lib/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:178:in `run_proc' /home/swistak/rails+backgroundrb/vendor/plugins/backgroundrb/server/lib/back groundrb_server.rb:301:in `run' script/backgroundrb:29 From eimorton at gmail.com Tue Jan 23 08:48:58 2007 From: eimorton at gmail.com (Erik Morton) Date: Tue, 23 Jan 2007 08:48:58 -0500 Subject: [Backgroundrb-devel] Loading Rails Helpers in 1.2.1 Message-ID: <41C2BEF7-58F1-4974-A512-7B2476F44B4C@gmail.com> I'm having a problem where a worker cannot load a rails helper in rails 1.2.1 20070123-08:27:15 (4974) uninitialized constant FileImportWorker::CatalogsHelper - (NameError) 20070123-08:27:15 (4974) /Users/erik/Documents/projects/myproject/ trunk/config/../vendor/rails/activerecord/lib/../../activesupport/lib/ active_support/dependencies.rb:478:in `const_missing' 20070123-08:27:15 (4974) /Users/erik/Documents/projects/myproject/ trunk/lib/workers/file_import_worker.rb:11 The CatalogsHelper is in app/helpers/catalogs_helper.rb, however it looks like "someone" thinks that the helper is an inner helper of the Worker. Any thoughts? Erik From ezmobius at gmail.com Tue Jan 23 14:01:34 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Tue, 23 Jan 2007 11:01:34 -0800 Subject: [Backgroundrb-devel] Loading Rails Helpers in 1.2.1 In-Reply-To: <41C2BEF7-58F1-4974-A512-7B2476F44B4C@gmail.com> References: <41C2BEF7-58F1-4974-A512-7B2476F44B4C@gmail.com> Message-ID: <35747E17-4245-4DEC-943E-DECDB13B3A69@brainspl.at> On Jan 23, 2007, at 5:48 AM, Erik Morton wrote: > I'm having a problem where a worker cannot load a rails helper in > rails 1.2.1 > > 20070123-08:27:15 (4974) uninitialized constant > FileImportWorker::CatalogsHelper - (NameError) > 20070123-08:27:15 (4974) /Users/erik/Documents/projects/myproject/ > trunk/config/../vendor/rails/activerecord/lib/../../activesupport/lib/ > active_support/dependencies.rb:478:in `const_missing' > 20070123-08:27:15 (4974) /Users/erik/Documents/projects/myproject/ > trunk/lib/workers/file_import_worker.rb:11 > > The CatalogsHelper is in app/helpers/catalogs_helper.rb, however it > looks like "someone" thinks that the helper is an inner helper of the > Worker. Any thoughts? > > Erik How are you trying to include that helper in your worker class? You probably need to prefix it with :: so instead of include CatalogsHelper try include ::CatalogsHelper Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From ezmobius at gmail.com Tue Jan 23 14:03:42 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Tue, 23 Jan 2007 11:03:42 -0800 Subject: [Backgroundrb-devel] Getting results from a dead worker. example? In-Reply-To: <1B16C983-1AF9-4DCD-8586-56925625517F@resourcestudio.nl> References: <1B16C983-1AF9-4DCD-8586-56925625517F@resourcestudio.nl> Message-ID: On Jan 23, 2007, at 3:19 AM, Tomasz Kaye wrote: > I'm having a little difficulty understanding how to retrieve results > from deceased workers (from the documentation it seems that it is > possible to do this). > > I pasted my simple test below. If anyone could point out what i > should be doing differently i'd be very grateful. > > My test worker: > > class TestWorker < BackgrounDRb::Worker::RailsBase > def do_work(args) > results[:done_with_do_work] = true > self.delete > end > end > TestWorker.register > > My rake task: > > task :tester => :environment do > k=MiddleMan.new_worker( > :class => :test_worker > ) > sleep 1 # the worker will die during this pause > # next line gives a nil object error > puts "done_with_do_work=#{MiddleMan.worker(k).results > [:done_with_do_work]||"not available"}" > end I am thinking about changing the way we store results. I think it might make a lot more sense to use a database table for results. The Results worker has been problematic. So for now I suggest storing any results you need in a db table and get the results in rails from said table. I hope to have some time soon to work on this but I am pretty busy at the moment. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From eimorton at gmail.com Wed Jan 24 17:46:16 2007 From: eimorton at gmail.com (Erik Morton) Date: Wed, 24 Jan 2007 17:46:16 -0500 Subject: [Backgroundrb-devel] failed to find slave socket Message-ID: I'm having a strange issue. The following error is printed to the backgroundrb_server.log file: failed to find slave socket - (RuntimeError) 20070124-17:41:29 (805) /usr/local/lib/ruby/gems/1.8/gems/slave-1.2.0/ lib/slave.rb:462:in `initialize' 20070124-17:41:29 (805) /Users/erik/Documents/projects/productblazer/ trunk/vendor/plugins/backgroundrb/server/lib/backgroundrb/ middleman.rb:210:in `new_worker' What's strange is that no exception reaches the console: >> MiddleMan.new_worker(:class => :verification_email_delivery_worker) => "fafbd1e29be8b802aef4a4ffc1a35754" Any thoughts? it's a fairly straight forward error message, but I can't understand why this worker would have an issue with its socket file when several others do not have this problem. From jrobbins at cmj.com Thu Jan 25 10:56:14 2007 From: jrobbins at cmj.com (Jacob Robbins) Date: Thu, 25 Jan 2007 10:56:14 -0500 Subject: [Backgroundrb-devel] render rhtml templates in worker Message-ID: <45B8D31E.8050002@cmj.com> I'm trying to make a worker that will render a large page to a file, very similar to what rails' builtin cacheing does except with the rendering done outside of rails. The only advice I've found is to use ActionController::Integration::Session.new but this doesn't seem to allow setting session variables the way the functional tests do. Is there a way to call a controller's methods or render an rhtml template from a background worker? -Jacob From jrobbins at cmj.com Thu Jan 25 16:45:52 2007 From: jrobbins at cmj.com (Jacob Robbins) Date: Thu, 25 Jan 2007 16:45:52 -0500 Subject: [Backgroundrb-devel] render rhtml templates in worker In-Reply-To: <45B8D31E.8050002@cmj.com> References: <45B8D31E.8050002@cmj.com> Message-ID: <45B92510.1010708@cmj.com> So i have not figured out any sane way to access controllers inside of backgroundrb or other rails-working scripts but instead i've resorted to rendering my rhtml templates directly using the ERB module that rails already includes from ruby standard lib. There are a few limitations to using ERB in the raw: - it doesn't understand the trailing dash in <% -%> so you have to strip those. - obviously it doesn't know about any rails helper methods although i think you might be able to explicitly include their classes. - you have to pass it a binding to your namespace or else it won't be able to access any instance variables Here's an example that works from inside of a model class: #load template into ERB object for rendering erb = ERB.new( IO.read( rhtml_template_path ) ) #set instance variables for rendering @report = self @chart = @report.chart # in order for the erb template to access the instance variables # we must pass it a binding to this namespace b = binding #render template with instance variables rendered_result = erb.result(b) One upside to giving up all the rails framework help is that it runs a bit faster and lighter. -Jacob Jacob Robbins wrote: > I'm trying to make a worker that will render a large page to a file, > very similar to what rails' builtin cacheing does except with the > rendering done outside of rails. > > The only advice I've found is to use > ActionController::Integration::Session.new but this doesn't seem to > allow setting session variables the way the functional tests do. Is > there a way to call a controller's methods or render an rhtml template > from a background worker? > > -Jacob > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From mike.aizatsky at gmail.com Sat Jan 27 10:01:09 2007 From: mike.aizatsky at gmail.com (Mike Aizatsky) Date: Sat, 27 Jan 2007 18:01:09 +0300 Subject: [Backgroundrb-devel] Debugging stale backgroundrb Message-ID: <49e1d9e50701270701s2468a493y2387e89f51cd1ef7@mail.gmail.com> Hi! As you might remember I'm having a problem of backgroundrb stopping calling my workers after some period of time. I tried adding logging to backgroundrb source code but it didn't help. So, after digging through internet I've found several gdb tools and here's what I've discovered: After attaching to a backgroundrb ruby process it turns out that it waits for some process to exit. Here's the "caller" for current thread: ["/opt/local/lib/ruby/gems/1.8/gems/slave-1.2.0/lib/slave.rb:491:in `detach'", "/opt/local/lib/ruby/gems/1.8/gems/slave-1.2.0/lib/slave.rb:489:in `initialize'", "/opt/local/lib/ruby/gems/1.8/gems/slave-1.2.0/lib/slave.rb:489:in `new'", "/opt/local/lib/ruby/gems/1.8/gems/slave-1.2.0/lib/slave.rb:489:in `detach'", "/opt/local/lib/ruby/gems/1.8/gems/slave-1.2.0/lib/slave.rb:431:in `initialize'", "/u/apps/learnbyrote/releases/20070125084747/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in `new'", "/u/apps/learnbyrote/releases/20070125084747/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in `new_worker'", "/u/apps/learnbyrote/releases/20070125084747/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch'", "/u/apps/learnbyrote/releases/20070125084747/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `initialize'", "/u/apps/learnbyrote/releases/20070125084747/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `new'", "/u/apps/learnbyrote/releases/20070125084747/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `dispatch'", "/u/apps/learnbyrote/releases/20070125084747/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in `new_worker'", "/u/apps/learnbyrote/releases/20070125084747/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:100:in `setup'", "/u/apps/learnbyrote/releases/20070125084747/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:306:in `run'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:186:in `call'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:186:in `start_proc'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/daemonize.rb:192:in `call'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/daemonize.rb:192:in `call_as_daemon'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:190:in `start_proc'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/application.rb:226:in `start'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/controller.rb:69:in `run'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons.rb:182:in `run_proc'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/cmdline.rb:94:in `call'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons/cmdline.rb:94:in `catch_exceptions'", "/opt/local/lib/ruby/gems/1.8/gems/daemons-1.0.4/lib/daemons.rb:181:in `run_proc'", "/u/apps/learnbyrote/releases/20070125084747/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in `run'", "/u/apps/learnbyrote/current/script/backgroundrb:29"] It's apparent that some Slave is waiting for some process to exit. After issuing "eval "ObjectSpace.each_object(Slave){|x| p x if !x.status}"" I've got a strange result though: #, @lifeline=#, nil], @fds=[9, 10], @pid=27245, @socket=#, @object_id=27657260, @owner=27245>, @socket_creation_attempts=42, @dumped=nil, @pid=27248, @status=nil, @debug=false, @object=#, @socket="/tmp/backgroundrb.27243/backgroundrb_results_0_0.488948936927155", @at_exit=nil, @waiter=#, @uri="drbunix:///tmp/backgroundrb.27243/backgroundrb_results_0_0.488948936927155", @psname="backgroundrb_results", @threadsafe=false> #, @lifeline=#, nil], @fds=[5, 6], @pid=27245, @socket=#, @object_id=27704370, @owner=27245>, @socket_creation_attempts=42, @dumped=nil, @pid=27246, @status=nil, @debug=false, @object=#, @socket="/tmp/backgroundrb.27243/backgroundrb_logger_0_0.488948936927155", @at_exit=nil, @waiter=#, @uri="drbunix:///tmp/backgroundrb.27243/backgroundrb_logger_0_0.488948936927155", @psname="backgroundrb_logger", @threadsafe=false> It means that two only slave which are waiting are slaves for logger and results. That's kinda strange. Do you have any ideas what can I check? I'm keeping the stalled process for a while in case anybody have any ideas. -- Regards, Mike From mike.aizatsky at gmail.com Sat Jan 27 10:03:16 2007 From: mike.aizatsky at gmail.com (Mike Aizatsky) Date: Sat, 27 Jan 2007 18:03:16 +0300 Subject: [Backgroundrb-devel] Memory leaks in backgroundrb Message-ID: <49e1d9e50701270703y22101b49v35e099a90e30f540@mail.gmail.com> While debugging stale backgroundrb it became apparent that there're memory leaks in it. Here's top object counts dump: 36715 String 6211 Array 5598 Proc 3150 Hash 1478 DRb::DRbObject 1313 Regexp 1272 Class 750 Thread 741 Socket 739 Slave 739 Slave::LifeLine 737 Process::Status 691 DrillReminderWorker 391 Module 160 Range 75 Gem::Version 73 XSD::QName It's easy to see that loads of threads and slaves are present in the process. It also has references to 691 workers! In case there might be some problems with my worker here's its full code: class DrillReminderWorker < BackgrounDRb::Worker::RailsBase def do_work(args) logger.info "DrillReminderSender started" t = Time.now.gmtime tsec = t.sec + t.min*60 + t.hour*60*60 logger.info "utc seconds: #{tsec}" User.find_all_to_send_drill_reminder(tsec).each do |u| Notification.deliver_drill_reminder(u) u.update_attributes!( :drill_notification_last_send => TimeUtils.nowf ) end logger.info "DrillReminderSender end" self.delete end end DrillReminderWorker.register -- Regards, Mike From gethemant at gmail.com Sat Jan 27 17:53:04 2007 From: gethemant at gmail.com (Hemant Kumar) Date: Sun, 28 Jan 2007 04:23:04 +0530 Subject: [Backgroundrb-devel] Memory leaks in backgroundrb In-Reply-To: <49e1d9e50701270703y22101b49v35e099a90e30f540@mail.gmail.com> References: <49e1d9e50701270703y22101b49v35e099a90e30f540@mail.gmail.com> Message-ID: <1169938384.27083.8.camel@localhost.localdomain> On Sat, 2007-01-27 at 18:03 +0300, Mike Aizatsky wrote: > While debugging stale backgroundrb it became apparent that there're > memory leaks in it. Here's top object counts dump: > > 36715 String > 6211 Array > 5598 Proc > 3150 Hash > 1478 DRb::DRbObject > 1313 Regexp > 1272 Class > 750 Thread > 741 Socket > 739 Slave > 739 Slave::LifeLine > 737 Process::Status > 691 DrillReminderWorker > 391 Module > 160 Range > 75 Gem::Version > 73 XSD::QName > > It's easy to see that loads of threads and slaves are present in the > process. It also has references to 691 workers! > > In case there might be some problems with my worker here's its full code: > > class DrillReminderWorker < BackgrounDRb::Worker::RailsBase > > def do_work(args) > logger.info "DrillReminderSender started" > t = Time.now.gmtime > tsec = t.sec + t.min*60 + t.hour*60*60 > > logger.info "utc seconds: #{tsec}" > > User.find_all_to_send_drill_reminder(tsec).each do |u| > Notification.deliver_drill_reminder(u) > u.update_attributes!( > :drill_notification_last_send => TimeUtils.nowf > ) > end > > logger.info "DrillReminderSender end" > > self.delete > end > > end > DrillReminderWorker.register > > For oneshot workers, I use explicit exit from the worker and it works, rather than using self.delete, however delete would also work as documented. From lapomme00 at gmail.com Sun Jan 28 22:52:30 2007 From: lapomme00 at gmail.com (Brett Walker) Date: Mon, 29 Jan 2007 11:52:30 +0800 Subject: [Backgroundrb-devel] rails_env configuration conflict... Message-ID: I've found a conflict in the way the configuration file is handled, in particular effecting the setting of the ENV['RAILS_ENV'] value. When I attempted to run a worker in production, it would run fine the first time - the second time would fail because it was trying to access the development database. I had created a 'backgroundrb_prodcution.yml' file that I was passing in when starting up backgroundrb. Setting the ENV['RAILS_ENV'] to production didn't help. In BackgrounDRb::Config, it set the ENV['RAILS_ENV'] to the value :rails_env value in the config file, and defaults to development. What seems to be happening is that when the Rails environment is getting loaded for a new worker (I guess after the first time), then BackgrounDRb::Config class gets executed. The config file doesn't seem to be specified - so it defaults to reading the default backgroundrb.yml file, which sets the :rails_env to development. If I remove the :rails_env line from the backgroundrb.yml file, and set RAILS_ENV when I start backgroundrb, it works. Not sure how to fix the problem in general. Cheers, Brett From jrobbins at cmj.com Mon Jan 29 11:51:30 2007 From: jrobbins at cmj.com (Jacob Robbins) Date: Mon, 29 Jan 2007 11:51:30 -0500 Subject: [Backgroundrb-devel] rails_env configuration conflict... In-Reply-To: References: Message-ID: <45BE2612.8020407@cmj.com> it seems that the way backgroundrb is intended to be used is to keep backgroundrb.yml out of subversion via svnignore properties and then maintain separate copies of it on each server. it would be nice if more than one method of configuration was fully supported, perhaps you could document the specific cases that you have found to misbehave and add them to the trac. Someone else on the list mentioned that the -r commandline option to script/backgroundrb start is also inconsistent enough to prevent it's use in production. -Jacob Brett Walker wrote: > I've found a conflict in the way the configuration file is handled, in > particular effecting the setting of the ENV['RAILS_ENV'] value. > > When I attempted to run a worker in production, it would run fine the > first time - the second time would fail because it was trying to > access the development database. > > I had created a 'backgroundrb_prodcution.yml' file that I was passing > in when starting up backgroundrb. Setting the ENV['RAILS_ENV'] to > production didn't help. > > In BackgrounDRb::Config, it set the ENV['RAILS_ENV'] to the value > :rails_env value in the config file, and defaults to development. > > What seems to be happening is that when the Rails environment is > getting loaded for a new worker (I guess after the first time), then > BackgrounDRb::Config class gets executed. The config file doesn't > seem to be specified - so it defaults to reading the default > backgroundrb.yml file, which sets the :rails_env to development. > > If I remove the :rails_env line from the backgroundrb.yml file, and > set RAILS_ENV when I start backgroundrb, it works. > > Not sure how to fix the problem in general. > > Cheers, > Brett > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From eimorton at gmail.com Mon Jan 29 13:37:20 2007 From: eimorton at gmail.com (Erik Morton) Date: Mon, 29 Jan 2007 13:37:20 -0500 Subject: [Backgroundrb-devel] failed to find slave socket In-Reply-To: References: Message-ID: I think the socket filename was too long. I shortened the name of the worker to verification_email_worker and it loads correctly on OSX now. I haven't tested linux yet. Erik On Jan 24, 2007, at 5:46 PM, Erik Morton wrote: > I'm having a strange issue. The following error is printed to the > backgroundrb_server.log file: > > failed to find slave socket verification_email_delivery_worker_fafbd1e29be8b802aef4a4ffc1a35754_0_ > 0.126366358217085> - (RuntimeError) > 20070124-17:41:29 (805) /usr/local/lib/ruby/gems/1.8/gems/ > slave-1.2.0/lib/slave.rb:462:in `initialize' > 20070124-17:41:29 (805) /Users/erik/Documents/projects/ > productblazer/trunk/vendor/plugins/backgroundrb/server/lib/ > backgroundrb/middleman.rb:210:in `new_worker' > > What's strange is that no exception reaches the console: > >> MiddleMan.new_worker(:class => :verification_email_delivery_worker) > => "fafbd1e29be8b802aef4a4ffc1a35754" > > Any thoughts? it's a fairly straight forward error message, but I > can't understand why this worker would have an issue with its > socket file when several others do not have this problem. From patrick at xblabs.com Mon Jan 29 16:33:21 2007 From: patrick at xblabs.com (Patrick Crosby) Date: Mon, 29 Jan 2007 16:33:21 -0500 Subject: [Backgroundrb-devel] loading C extension in worker causes bus error on OS X only Message-ID: In all likelihood, this doesn't have anything to do with backgroundrb, but I'm stuck so I thought someone might be able to help. I have a pretty simple C extension that I built into a gem and have installed on my system. It works fine when required from rails (1.2.1). But when I have a Backgroundrb worker class use the extension (under os x), I get: /usr/local/lib/ruby/gems/1.8/gems/opalfx-0.1.1582/lib/ofx_helper.bundle: [BUG] Bus Error ruby 1.8.4 (2005-12-24) [i686-darwin8.8.1] (That's the right version of ruby). I've tried all kinds of stuff. I installed a trace function, but it's crashing on the require statement. Trying to isolate the problem, even using irb, it gets a bus error (so definitely not backgroundrb's fault). I tried it on a linux server (through irb) and it worked fine. Anyone have any ideas? Thanks. patrick From masonhale at gmail.com Mon Jan 29 17:03:01 2007 From: masonhale at gmail.com (Mason Hale) Date: Mon, 29 Jan 2007 16:03:01 -0600 Subject: [Backgroundrb-devel] loading C extension in worker causes bus error on OS X only In-Reply-To: References: Message-ID: <8bca3aa10701291403o4460d15dlc43e0aac55d6713e@mail.gmail.com> I ran into this issue before: http://rubyforge.org/pipermail/backgroundrb-devel/2006-December/000594.html This is apparently a bug in the way external libraries are loaded on Mac OS X, in Ruby and other scripting languages. It has to do with the contents of the argv array changing between the launch of the scripting environment and the loading of the external module. It does not appear to be specific to BackgroundRb or even Ruby. A search for "mac os x bus error" in google will find reports of similar issues cropping up in the Perl and Python communities too. I'm working around the issue by using the pure-ruby Postgres driver on Mac OS. If you find a better solution, I'd very much appreciate a follow-up message with a better workaround. It's useful to note that a similar issue was reported in Rails when using script/console, but a work around was found for that case. best regards, Mason On 1/29/07, Patrick Crosby wrote: > > In all likelihood, this doesn't have anything to do with backgroundrb, > but I'm stuck so I thought someone might be able to help. > > I have a pretty simple C extension that I built into a gem and have > installed on my system. It works fine when required from rails > (1.2.1). > > But when I have a Backgroundrb worker class use the extension (under > os x), I get: > > /usr/local/lib/ruby/gems/1.8/gems/opalfx-0.1.1582/lib/ofx_helper.bundle: > [BUG] Bus Error > ruby 1.8.4 (2005-12-24) [i686-darwin8.8.1] > > (That's the right version of ruby). > > I've tried all kinds of stuff. I installed a trace function, but it's > crashing on the require statement. > > Trying to isolate the problem, even using irb, it gets a bus error (so > definitely not backgroundrb's fault). I tried it on a linux server > (through irb) and it worked fine. > > Anyone have any ideas? > > Thanks. > > patrick > _______________________________________________ > 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/20070129/faa76476/attachment.html From patrick at xblabs.com Mon Jan 29 17:14:14 2007 From: patrick at xblabs.com (Patrick Crosby) Date: Mon, 29 Jan 2007 17:14:14 -0500 Subject: [Backgroundrb-devel] loading C extension in worker causes bus error on OS X only In-Reply-To: <8bca3aa10701291403o4460d15dlc43e0aac55d6713e@mail.gmail.com> References: <8bca3aa10701291403o4460d15dlc43e0aac55d6713e@mail.gmail.com> Message-ID: I read the thread about specifying -r args on the irb command line causing bus errors on os x (for reference, this is the main one: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/142806 ), but why would that affect the backgroundrb server? The server starts up fine, but once it hits code that causes the require of the C extension, it gets the bus error. I get the same problem using rails' script/console when I call something that requires this extension. (but again, all works fine in a rails app, or on linux). Thanks. patrick On 1/29/07, Mason Hale wrote: > I ran into this issue before: > http://rubyforge.org/pipermail/backgroundrb-devel/2006-December/000594.html > > This is apparently a bug in the way external libraries are loaded on Mac OS > X, in Ruby and other scripting languages. It has to do with the contents of > the argv array changing between the launch of the scripting environment and > the loading of the external module. It does not appear to be specific to > BackgroundRb or even Ruby. A search for "mac os x bus error" in google will > find reports of similar issues cropping up in the Perl and Python > communities too. > > I'm working around the issue by using the pure-ruby Postgres driver on Mac > OS. If you find a better solution, I'd very much appreciate a follow-up > message with a better workaround. It's useful to note that a similar issue > was reported in Rails when using script/console, but a work around was found > for that case. > > best regards, > Mason > > > > > > On 1/29/07, Patrick Crosby wrote: > > > > In all likelihood, this doesn't have anything to do with backgroundrb, > > but I'm stuck so I thought someone might be able to help. > > > > I have a pretty simple C extension that I built into a gem and have > > installed on my system. It works fine when required from rails > > (1.2.1). > > > > But when I have a Backgroundrb worker class use the extension (under > > os x), I get: > > > > > /usr/local/lib/ruby/gems/1.8/gems/opalfx-0.1.1582/lib/ofx_helper.bundle: > > [BUG] Bus Error > > ruby 1.8.4 (2005-12-24) [ i686-darwin8.8.1] > > > > (That's the right version of ruby). > > > > I've tried all kinds of stuff. I installed a trace function, but it's > > crashing on the require statement. > > > > Trying to isolate the problem, even using irb, it gets a bus error (so > > definitely not backgroundrb's fault). I tried it on a linux server > > (through irb) and it worked fine. > > > > Anyone have any ideas? > > > > Thanks. > > > > patrick > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > -- http://www.xblabs.com From masonhale at gmail.com Mon Jan 29 17:32:56 2007 From: masonhale at gmail.com (Mason Hale) Date: Mon, 29 Jan 2007 16:32:56 -0600 Subject: [Backgroundrb-devel] loading C extension in worker causes bus error on OS X only In-Reply-To: References: <8bca3aa10701291403o4460d15dlc43e0aac55d6713e@mail.gmail.com> Message-ID: <8bca3aa10701291432l400269cbm7d5df32117872b5e@mail.gmail.com> I haven't had time to track down and fix this issue wrt backgroundrb. I'm hobbling along with the pure-ruby postgres driver for now. My strong suspicion is that it has to do with nullify-ing the contents of the argv array, say by writing to $0 at some point. Where that might be happening, I don't know. Mason On 1/29/07, Patrick Crosby wrote: > > I read the thread about specifying -r args on the irb command line > causing bus errors on os x (for reference, this is the main one: > http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/142806 ), > but why would that affect the backgroundrb server? The server starts > up fine, but once it hits code that causes the require of the C > extension, it gets the bus error. > > I get the same problem using rails' script/console when I call > something that requires this extension. > > (but again, all works fine in a rails app, or on linux). > > Thanks. > > patrick > > On 1/29/07, Mason Hale wrote: > > I ran into this issue before: > > > http://rubyforge.org/pipermail/backgroundrb-devel/2006-December/000594.html > > > > This is apparently a bug in the way external libraries are loaded on Mac > OS > > X, in Ruby and other scripting languages. It has to do with the contents > of > > the argv array changing between the launch of the scripting environment > and > > the loading of the external module. It does not appear to be specific to > > BackgroundRb or even Ruby. A search for "mac os x bus error" in google > will > > find reports of similar issues cropping up in the Perl and Python > > communities too. > > > > I'm working around the issue by using the pure-ruby Postgres driver on > Mac > > OS. If you find a better solution, I'd very much appreciate a follow-up > > message with a better workaround. It's useful to note that a similar > issue > > was reported in Rails when using script/console, but a work around was > found > > for that case. > > > > best regards, > > Mason > > > > > > > > > > > > On 1/29/07, Patrick Crosby wrote: > > > > > > In all likelihood, this doesn't have anything to do with backgroundrb, > > > but I'm stuck so I thought someone might be able to help. > > > > > > I have a pretty simple C extension that I built into a gem and have > > > installed on my system. It works fine when required from rails > > > (1.2.1). > > > > > > But when I have a Backgroundrb worker class use the extension (under > > > os x), I get: > > > > > > > > /usr/local/lib/ruby/gems/1.8/gems/opalfx-0.1.1582/lib/ofx_helper.bundle: > > > [BUG] Bus Error > > > ruby 1.8.4 (2005-12-24) [ i686-darwin8.8.1] > > > > > > (That's the right version of ruby). > > > > > > I've tried all kinds of stuff. I installed a trace function, but it's > > > crashing on the require statement. > > > > > > Trying to isolate the problem, even using irb, it gets a bus error (so > > > definitely not backgroundrb's fault). I tried it on a linux server > > > (through irb) and it worked fine. > > > > > > Anyone have any ideas? > > > > > > Thanks. > > > > > > patrick > > > _______________________________________________ > > > Backgroundrb-devel mailing list > > > Backgroundrb-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > > > > > > -- > http://www.xblabs.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070129/424e7304/attachment-0001.html From chris at rupture.com Mon Jan 29 19:16:35 2007 From: chris at rupture.com (Chris Bruce) Date: Mon, 29 Jan 2007 16:16:35 -0800 Subject: [Backgroundrb-devel] Worker Termination Message-ID: Do worker processes end after the do_work is complete or do they need to be terminated explicitly? Thanks, Chris From patrick at xblabs.com Mon Jan 29 22:57:15 2007 From: patrick at xblabs.com (Patrick Crosby) Date: Mon, 29 Jan 2007 22:57:15 -0500 Subject: [Backgroundrb-devel] loading C extension in worker causes bus error on OS X only In-Reply-To: <8bca3aa10701291432l400269cbm7d5df32117872b5e@mail.gmail.com> References: <8bca3aa10701291403o4460d15dlc43e0aac55d6713e@mail.gmail.com> <8bca3aa10701291432l400269cbm7d5df32117872b5e@mail.gmail.com> Message-ID: So I got it working...I edited script/backgroundrb and put the require for the C extension in the script right before the last line where it runs the server. Doesn't make any sense, but it works, so that's good enough for me for now. patrick On 1/29/07, Mason Hale wrote: > > I haven't had time to track down and fix this issue wrt backgroundrb. I'm > hobbling along with the pure-ruby postgres driver for now. > > My strong suspicion is that it has to do with nullify-ing the contents of > the argv array, say by writing to $0 at some point. Where that might be > happening, I don't know. > > > Mason > > On 1/29/07, Patrick Crosby wrote: > > I read the thread about specifying -r args on the irb command line > > causing bus errors on os x (for reference, this is the main one: > > > http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/142806 > ), > > but why would that affect the backgroundrb server? The server starts > > up fine, but once it hits code that causes the require of the C > > extension, it gets the bus error. > > > > I get the same problem using rails' script/console when I call > > something that requires this extension. > > > > (but again, all works fine in a rails app, or on linux). > > > > Thanks. > > > > patrick > > > > On 1/29/07, Mason Hale wrote: > > > I ran into this issue before: > > > > http://rubyforge.org/pipermail/backgroundrb-devel/2006-December/000594.html > > > > > > This is apparently a bug in the way external libraries are loaded on Mac > OS > > > X, in Ruby and other scripting languages. It has to do with the contents > of > > > the argv array changing between the launch of the scripting environment > and > > > the loading of the external module. It does not appear to be specific to > > > BackgroundRb or even Ruby. A search for "mac os x bus error" in google > will > > > find reports of similar issues cropping up in the Perl and Python > > > communities too. > > > > > > I'm working around the issue by using the pure-ruby Postgres driver on > Mac > > > OS. If you find a better solution, I'd very much appreciate a follow-up > > > message with a better workaround. It's useful to note that a similar > issue > > > was reported in Rails when using script/console, but a work around was > found > > > for that case. > > > > > > best regards, > > > Mason > > > > > > > > > > > > > > > > > > On 1/29/07, Patrick Crosby < patrick at xblabs.com> wrote: > > > > > > > > In all likelihood, this doesn't have anything to do with backgroundrb, > > > > but I'm stuck so I thought someone might be able to help. > > > > > > > > I have a pretty simple C extension that I built into a gem and have > > > > installed on my system. It works fine when required from rails > > > > (1.2.1). > > > > > > > > But when I have a Backgroundrb worker class use the extension (under > > > > os x), I get: > > > > > > > > > > > > /usr/local/lib/ruby/gems/1.8/gems/opalfx-0.1.1582/lib/ofx_helper.bundle: > > > > [BUG] Bus Error > > > > ruby 1.8.4 (2005-12-24) [ i686-darwin8.8.1] > > > > > > > > (That's the right version of ruby). > > > > > > > > I've tried all kinds of stuff. I installed a trace function, but it's > > > > crashing on the require statement. > > > > > > > > Trying to isolate the problem, even using irb, it gets a bus error (so > > > > definitely not backgroundrb's fault). I tried it on a linux server > > > > (through irb) and it worked fine. > > > > > > > > Anyone have any ideas? > > > > > > > > Thanks. > > > > > > > > patrick > > > > _______________________________________________ > > > > Backgroundrb-devel mailing list > > > > Backgroundrb-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > > > > > > > > > > > > -- > > http://www.xblabs.com > > > > -- http://www.xblabs.com From Horst.Rischbode at t-systems.com Tue Jan 30 05:18:03 2007 From: Horst.Rischbode at t-systems.com (Rischbode, Horst) Date: Tue, 30 Jan 2007 11:18:03 +0100 Subject: [Backgroundrb-devel] Logging doesn't work Message-ID: <9C72320BC4F0B34CB814EAA865AA88E301084900@S4DE9JSAAIK.nord.t-com.de> Sorry for perhaps asking a Newbie-Question, but couldn't find any answer elsewhere (and even not in the archieves...). Trying to import files in my rails app using backgroundrb and trying to examine the backgroundrb.log file. But it isn't updated. The pid-file is updated to the correct value every time I start drb. I'm working on an windows-machine (XP Prof). Tried to set RAILS_ROOT in environment.rb manually. But that didn't work as well (even after restart all). This is the code for my worker: class UpdateLogdbWorker < BackgrounDRb::Rails def do_work(args) @logger.info("Call successful") # do some more stuff end end This is, what my call looks like: MiddleMan.new_worker(:class => update_logdb_worker) Any advice would be appreciated! Regards Horst From Horst.Rischbode at t-systems.com Tue Jan 30 07:26:23 2007 From: Horst.Rischbode at t-systems.com (Rischbode, Horst) Date: Tue, 30 Jan 2007 13:26:23 +0100 Subject: [Backgroundrb-devel] Logging doesn't work Message-ID: <9C72320BC4F0B34CB814EAA865AA88E301084906@S4DE9JSAAIK.nord.t-com.de> Sorry for perhaps asking a Newbie-Question, but couldn't find any answer elsewhere (and even not in the archieves...). Trying to import files in my rails app using backgroundrb and trying to examine the backgroundrb.log file. But it isn't updated. The pid-file is updated to the correct value every time I start drb. I'm working on an windows-machine (XP Prof). This all has worked well on my W2k development system. The only additional change was the update to rails 1.2.1. Tried to set RAILS_ROOT in environment.rb manually. But that didn't work as well (even after restart all). This is the code for my worker: class UpdateLogdbWorker < BackgrounDRb::Rails def do_work(args) @logger.info("Call successful") # do the import stuff end end This is, what my call looks like: MiddleMan.new_worker(:class => update_logdb_worker) The call of the MiddleMan raises no errors, a job_key is given back. Any advice would be appreciated! Regards Horst From jacob at jacobatzen.dk Tue Jan 30 09:25:49 2007 From: jacob at jacobatzen.dk (Jacob Atzen) Date: Tue, 30 Jan 2007 15:25:49 +0100 Subject: [Backgroundrb-devel] Backgroundrb weirdness with multiple mongrels Message-ID: <20070130142549.GA83695@apoc.jacobatzen.dk> 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: 20070130-12:03:03 (92473) failed to find slave socket - (RuntimeError) 20070130-12:03:03 (92473) /usr/local/lib/ruby/gems/1.8/gems/slave-1.2.0/lib/slave.rb:435:in `initialize' 20070130-12:03:03 (92473) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in `new' 20070130-12:03:03 (92473) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in `new_worker' 20070130-12:03:03 (92473) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch' 20070130-12:03:03 (92473) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `initialize' 20070130-12:03:03 (92473) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `new' 20070130-12:03:03 (92473) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `dispatch' 20070130-12:03:03 (92473) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in `new_worker' And: 20070130-12:00:05 (92080) connection closed - (DRb::DRbConnError) 20070130-12:00:05 (92080) /usr/local/lib/ruby/1.8/drb/drb.rb:570:in `load' 20070130-12:00:05 (92080) /usr/local/lib/ruby/1.8/drb/drb.rb:632:in `recv_reply' 20070130-12:00:05 (92080) /usr/local/lib/ruby/1.8/drb/drb.rb:921:in `recv_reply' 20070130-12:00:05 (92080) /usr/local/lib/ruby/1.8/drb/drb.rb:1195:in `send_message' 20070130-12:00:05 (92080) /usr/local/lib/ruby/1.8/drb/drb.rb:1086:in `method_missing' 20070130-12:00:05 (92080) /usr/local/lib/ruby/1.8/drb/drb.rb:1170:in `open' 20070130-12:00:05 (92080) /usr/local/lib/ruby/1.8/drb/drb.rb:1085:in `method_missing' 20070130-12:00:05 (92080) /usr/local/lib/ruby/1.8/drb/drb.rb:1103:in `with_friend' 20070130-12:00:05 (92080) /usr/local/lib/ruby/1.8/drb/drb.rb:1084:in `method_missing' 20070130-12:00:05 (92080) /usr/local/lib/ruby/1.8/drb/drb.rb:1072:in `respond_to?' 20070130-12:00:05 (92080) /usr/local/lib/ruby/gems/1.8/gems/slave-1.2.0/lib/slave.rb:454:in `initialize' 20070130-12:00:05 (92080) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in `new' 20070130-12:00:05 (92080) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in `new_worker' 20070130-12:00:05 (92080) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch' 20070130-12:00:05 (92080) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `initialize' 20070130-12:00:05 (92080) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `new' 20070130-12:00:05 (92080) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `dispatch' 20070130-12:00:05 (92080) /usr/local/www/rails-apps/myapp/releases/20070130101502/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in `new_worker' 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? -- Thanks, - Jacob Atzen From jrobbins at cmj.com Tue Jan 30 11:21:31 2007 From: jrobbins at cmj.com (Jacob Robbins) Date: Tue, 30 Jan 2007 11:21:31 -0500 Subject: [Backgroundrb-devel] Worker Termination In-Reply-To: References: Message-ID: <45BF708B.50303@cmj.com> you need to self-terminate somewhere in your worker class by calling self.delete. Check the workers section of http://backgroundrb.rubyforge.org/ The assumption of the framework is that you want to be able to make long running workers. Chris Bruce wrote: > Do worker processes end after the do_work is complete or do they > need to be terminated explicitly? > > > Thanks, > > Chris > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From bill.walton at charter.net Tue Jan 30 12:55:58 2007 From: bill.walton at charter.net (Bill Walton) Date: Tue, 30 Jan 2007 11:55:58 -0600 Subject: [Backgroundrb-devel] Documentation location? Message-ID: <030c01c74497$e5cd3590$6401a8c0@Presario> I'm a little confused wrt the documentation. I'm using the 'old' version of Backgroundrb (the one at rubyforge). Is the documentation at rubyforge (http://backgroundrb.rubyforge.org/) for that version? Are there two sets of documentation now? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070130/0a00b619/attachment.html From ezmobius at gmail.com Tue Jan 30 14:12:36 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Tue, 30 Jan 2007 11:12:36 -0800 Subject: [Backgroundrb-devel] Documentation location? In-Reply-To: <030c01c74497$e5cd3590$6401a8c0@Presario> References: <030c01c74497$e5cd3590$6401a8c0@Presario> Message-ID: <719E9500-E8A3-48BA-9F5F-E4D3296E4E9D@brainspl.at> On Jan 30, 2007, at 9:55 AM, Bill Walton wrote: > I'm a little confused wrt the documentation. I'm using the 'old' > version of Backgroundrb (the one at rubyforge). Is the > documentation at rubyforge (http://backgroundrb.rubyforge.org/) for > that version? Are there two sets of documentation now? > > Thanks, > Bill There is no live rdoc for the old version of the plugin right now. That link above is for the new plugin. 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 Tue Jan 30 14:58:22 2007 From: bill.walton at charter.net (Bill Walton) Date: Tue, 30 Jan 2007 13:58:22 -0600 Subject: [Backgroundrb-devel] install problem Message-ID: <003701c744a8$ff5a4910$6401a8c0@Presario> I apologize if this is a dup. My anti-productivity, anti-virus software said it was rejected. Then it turns out my ISP's mailserver was the problem. -------------------- First, this is my first install on Linux. I've done my dev work on a WinXP box. So I'd guess this is definitely a newbie problem. I've just gotten a 'semi-dedicated' account at a2hosting which is basically a VPS with support. I'm trying to get BackgrounDRb setup and a sandbox app I've developed on my WinXP box running on the box. When I run 'rake backgroundrb:setup' from the root of my app, I'm getting an 'rake aborted' error message. BUT, when I check the vendor/plugins/backgroundrb/script/backgroundrb directory the service, start, stop, and win32daemon files have been created. But when I do 'rake backgroundrb:start' from the app root, I get 'Backgroundrb is not installed. Run 'rake backgroundrb:setup' first!' Anybody got any ideas what I might be doing wrong? TIA, Bill From matthibcn at gmail.com Tue Jan 30 15:56:55 2007 From: matthibcn at gmail.com (matthibcn) Date: Tue, 30 Jan 2007 21:56:55 +0100 Subject: [Backgroundrb-devel] using file_column with backgrounDRb ? Message-ID: <45BFB117.7050404@gmail.com> Hi list, I am quite new to baclgrounDRB, so far I just tested the samples, so far it works fine, also I got it working the cronstyleway for testingpurposes. Now I have seen ppl are using bDRb for fileupload, especially with the file_column plugin. Unfortunatly there are only a few tutorials out there, well, more articles than tutorials in fact, and additionally the few I found are all outdated so far. Anyway: I am still wondering about the concept in a whole and asking myself, how do I shift now my working file_upload to the next step involving bgrDRb ? As for now I am just using the file_column plugin the normal way and have no clue where to start, what to pass to the worker, even what to give the worker to do..etc Well, you see, I am quite lost, so its also hard to be very specific asking you... Any hint would be very welcome, also I think I wont be the only one interested in all that staff best regards matthi From bill.walton at charter.net Tue Jan 30 17:02:07 2007 From: bill.walton at charter.net (Bill Walton) Date: Tue, 30 Jan 2007 16:02:07 -0600 Subject: [Backgroundrb-devel] backgroundrb (old version) on Rails 1.2.1? Message-ID: <00e201c744ba$48f107b0$6401a8c0@Presario> 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.html From chris at rupture.com Tue Jan 30 19:05:33 2007 From: chris at rupture.com (Chris Bruce) Date: Tue, 30 Jan 2007 16:05:33 -0800 Subject: [Backgroundrb-devel] Pool Size Message-ID: <2E6FD2EE-E9BE-4D51-8F07-4AD88CC40F82@rupture.com> I am not sure how pool size works or if it applies to the following situation: I would like a pool of 10 worker processes that basically all do the same thing (based on args i send). I would like to be able to pass args to the pool of workers and the next available one will handle it. If there happens to be 10 already processing, I would like the request to be queued until a worker is available. What is the best way to handle this? The docs say do_work only gets called on new_worker, and that I should call delete. But won't this in effect create a new process and delete the process? How can I call delete when I am not sure when the process will be done? Thanks for any insight/feedback. Chris