From christopher.k.hall at gmail.com Wed Nov 1 08:19:45 2006 From: christopher.k.hall at gmail.com (Chris Hall) Date: Wed, 1 Nov 2006 08:19:45 -0500 Subject: [Backgroundrb-devel] strange issue with backgroundrb behind apache/lighttpd Message-ID: I'm getting strange data back from my worker whenever I run our rails app with more than one dispatcher under lighttpd. just to give some info on what the app does: user submits data to rails app. rails app hands off data to worker, which goes and does it's thing, storing results in an array of response objects (the array is an attribute of the worker). the response object includes DRbUndumped. Back in the browser, ajax requests are made at 1 sec intervals to the rails app to check on how the worker is progressing. the app calls a method on the worker to get back any finished responses. an array of responses is passed back to the app and the data is used to update the browser. the size of the array is also used to decrement a counter to show the user how much work is left to complete until it gets to zero. When we have 1 dispatcher running, the app works great. as soon as we add 2 or more dispatchers to lighttpd, we get strange results in the counter. the counter will start displaying negative values. Now, what i think is happening is now that we introduced 2 dispatchers, the ajax request that is run every second is not queuing up as it would with 1 dispatcher and we have overlap of requests getting back the same data. i tested this by changing the request interval to 2 seconds and the counter now shows the correct values. but we have another problem. when testing with 2 or more people at the same time, we get the following error several times in the development log: Processing SearchController#get_responses (for 127.0.0.1 at 2006-11-01 07:47:07) [POST] Session ID: 671f4ba93603f34e036d9bbc65919ca7 Parameters: {"action"=>"get_responses", "controller"=>"search"} getting responses RangeError (0xdb677f22 is recycled object): (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:375:in `_id2ref' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:375:in `to_obj' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1402:in `to_obj' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1704:in `to_obj' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:613:in `recv_request' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:911:in `recv_request' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1530:in `init_with_cl ient' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1542:in `setup_messag e' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1494:in `perform' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1585:in `loop' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1581:in `start' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1430:in `run' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1427:in `start' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1347:in `initialize' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1627:in `start_servic e' (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/breakp oint.rb:375:in `activate_drb' (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispat cher.rb:81:in `prepare_breakpoint' (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispat cher.rb:68:in `prepare_application' (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispat cher.rb:37:in `dispatch' (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_h andler.rb:150:in `process_request' (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_h andler.rb:54:in `process!' (druby://localhost:42531) /usr/lib/ruby/site_ruby/1.8/fcgi.rb:612:in `each_c gi' (druby://localhost:42531) /usr/lib/ruby/site_ruby/1.8/fcgi.rb:117:in `sessio n' (druby://localhost:42531) /usr/lib/ruby/site_ruby/1.8/fcgi.rb:104:in `each_r equest' (druby://localhost:42531) /usr/lib/ruby/site_ruby/1.8/fcgi.rb:36:in `each' (druby://localhost:42531) /usr/lib/ruby/site_ruby/1.8/fcgi.rb:609:in `each_c gi' (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_h andler.rb:53:in `process!' (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_h andler.rb:23:in `process!' (druby://localhost:42531) /home/chall/radrails/workspace/chip2/public/dispat ch.fcgi:24 (druby://localhost:22222) /usr/lib/ruby/1.8/drb/invokemethod.rb:10:in `block _yield' (druby://localhost:22222) /usr/lib/ruby/1.8/drb/invokemethod.rb:17:in `perfo rm_with_block' (druby://localhost:22222) /usr/lib/ruby/1.8/drb/invokemethod.rb:14:in `each' /app/controllers/search_controller.rb:123:in `__bind_1162385227_815142' /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/core_ext/ object/extending.rb:44:in `[]' /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/core_ext/ object/extending.rb:44:in `instance_exec' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_view/helpers/protot ype_helper.rb:378:in `initialize' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb: 687:in `new' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb: 687:in `render_with_no_layout' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/layout.r b:253:in `render_without_benchmark' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/benchmar king.rb:53:in `render' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/benchmar king.rb:53:in `render' /app/controllers/search_controller.rb:110:in `get_responses' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb: 941:in `send' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb: 941:in `perform_action_without_filters' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/filters. rb:368:in `perform_action_without_benchmark' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/benchmar king.rb:69:in `perform_action_without_rescue' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/benchmar king.rb:69:in `perform_action_without_rescue' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/rescue.r b:82:in `perform_action' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb: 408:in `send' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/filters. rb:377:in `process_without_session_management_support' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/session_ management.rb:117:in `process' /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispatcher.rb:38:in `dispatch' /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_handler.rb:150:in `process_ request' /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_handler.rb:54:in `process!' /usr/lib/ruby/site_ruby/1.8/fcgi.rb:612:in `each_cgi' /usr/lib/ruby/site_ruby/1.8/fcgi.rb:117:in `session' /usr/lib/ruby/site_ruby/1.8/fcgi.rb:104:in `each_request' /usr/lib/ruby/site_ruby/1.8/fcgi.rb:36:in `each' /usr/lib/ruby/site_ruby/1.8/fcgi.rb:609:in `each_cgi' /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_handler.rb:53:in `process!' /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_handler.rb:23:in `process!' /home/chall/radrails/workspace/chip2/public/dispatch.fcgi:24 Rendering /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/te mplates/rescues/layout.rhtml (500 Internal Error) we can't figure out where the heck this is happening. there are only 2 references to some controller code on lines 123 and 110 which are 110: render :update do |page| 123: done_responses.each do |r| if anyone has any idea on what might be happening, we would truly appreciate it. Chris From skaar at waste.org Wed Nov 1 12:52:54 2006 From: skaar at waste.org (skaar) Date: Wed, 1 Nov 2006 11:52:54 -0600 Subject: [Backgroundrb-devel] strange issue with backgroundrb behind apache/lighttpd In-Reply-To: References: Message-ID: <20061101175254.GA25910@waste.org> any chance you could try to use 'results' for this, rather than an instance variable? is there a single worker instance serving different user sessions? /skaar * Chris Hall (christopher.k.hall at gmail.com) [061101 07:50]: > I'm getting strange data back from my worker whenever I run our rails > app with more than one dispatcher under lighttpd. > > just to give some info on what the app does: > > user submits data to rails app. rails app hands off data to worker, > which goes and does it's thing, storing results in an array of > response objects (the array is an attribute of the worker). the > response object includes DRbUndumped. > > Back in the browser, ajax requests are made at 1 sec intervals to the > rails app to check on how the worker is progressing. the app calls a > method on the worker to get back any finished responses. an array of > responses is passed back to the app and the data is used to update the > browser. the size of the array is also used to decrement a counter to > show the user how much work is left to complete until it gets to zero. > > When we have 1 dispatcher running, the app works great. as soon as we > add 2 or more dispatchers to lighttpd, we get strange results in the > counter. the counter will start displaying negative values. > > Now, what i think is happening is now that we introduced 2 > dispatchers, the ajax request that is run every second is not queuing > up as it would with 1 dispatcher and we have overlap of requests > getting back the same data. i tested this by changing the request > interval to 2 seconds and the counter now shows the correct values. > > but we have another problem. when testing with 2 or more people at > the same time, we get the following error several times in the > development log: > > Processing SearchController#get_responses (for 127.0.0.1 at 2006-11-01 07:47:07) > [POST] > Session ID: 671f4ba93603f34e036d9bbc65919ca7 > Parameters: {"action"=>"get_responses", "controller"=>"search"} > getting responses > > > RangeError (0xdb677f22 is recycled object): > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:375:in `_id2ref' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:375:in `to_obj' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1402:in `to_obj' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1704:in `to_obj' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:613:in `recv_request' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:911:in `recv_request' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1530:in `init_with_cl > ient' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1542:in `setup_messag > e' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1494:in `perform' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1585:in `loop' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1581:in `start' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1581:in `main_loop' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1430:in `run' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1427:in `start' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1347:in `initialize' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1627:in `new' > (druby://localhost:42531) /usr/lib/ruby/1.8/drb/drb.rb:1627:in `start_servic > e' > (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/breakp > oint.rb:375:in `activate_drb' > (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispat > cher.rb:81:in `prepare_breakpoint' > (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispat > cher.rb:68:in `prepare_application' > (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispat > cher.rb:37:in `dispatch' > (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_h > andler.rb:150:in `process_request' > (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_h > andler.rb:54:in `process!' > (druby://localhost:42531) /usr/lib/ruby/site_ruby/1.8/fcgi.rb:612:in `each_c > gi' > (druby://localhost:42531) /usr/lib/ruby/site_ruby/1.8/fcgi.rb:117:in `sessio > n' > (druby://localhost:42531) /usr/lib/ruby/site_ruby/1.8/fcgi.rb:104:in `each_r > equest' > (druby://localhost:42531) /usr/lib/ruby/site_ruby/1.8/fcgi.rb:36:in `each' > (druby://localhost:42531) /usr/lib/ruby/site_ruby/1.8/fcgi.rb:609:in `each_c > gi' > (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_h > andler.rb:53:in `process!' > (druby://localhost:42531) /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_h > andler.rb:23:in `process!' > (druby://localhost:42531) /home/chall/radrails/workspace/chip2/public/dispat > ch.fcgi:24 > (druby://localhost:22222) /usr/lib/ruby/1.8/drb/invokemethod.rb:10:in `block > _yield' > (druby://localhost:22222) /usr/lib/ruby/1.8/drb/invokemethod.rb:17:in `perfo > rm_with_block' > (druby://localhost:22222) /usr/lib/ruby/1.8/drb/invokemethod.rb:14:in `each' > /app/controllers/search_controller.rb:123:in `__bind_1162385227_815142' > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/core_ext/ > object/extending.rb:44:in `[]' > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/core_ext/ > object/extending.rb:44:in `instance_exec' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_view/helpers/protot > ype_helper.rb:378:in `initialize' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb: > 687:in `new' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb: > 687:in `render_with_no_layout' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/layout.r > b:253:in `render_without_benchmark' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/benchmar > king.rb:53:in `render' > /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/benchmar > king.rb:53:in `render' > /app/controllers/search_controller.rb:110:in `get_responses' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb: > 941:in `send' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb: > 941:in `perform_action_without_filters' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/filters. > rb:368:in `perform_action_without_benchmark' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/benchmar > king.rb:69:in `perform_action_without_rescue' > /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/benchmar > king.rb:69:in `perform_action_without_rescue' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/rescue.r > b:82:in `perform_action' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb: > 408:in `send' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/filters. > rb:377:in `process_without_session_management_support' > /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/session_ > management.rb:117:in `process' > /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispatcher.rb:38:in `dispatch' > /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_handler.rb:150:in `process_ > request' > /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_handler.rb:54:in `process!' > /usr/lib/ruby/site_ruby/1.8/fcgi.rb:612:in `each_cgi' > /usr/lib/ruby/site_ruby/1.8/fcgi.rb:117:in `session' > /usr/lib/ruby/site_ruby/1.8/fcgi.rb:104:in `each_request' > /usr/lib/ruby/site_ruby/1.8/fcgi.rb:36:in `each' > /usr/lib/ruby/site_ruby/1.8/fcgi.rb:609:in `each_cgi' > /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_handler.rb:53:in `process!' > /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/fcgi_handler.rb:23:in `process!' > /home/chall/radrails/workspace/chip2/public/dispatch.fcgi:24 > > > Rendering /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/te > mplates/rescues/layout.rhtml (500 Internal Error) > > > we can't figure out where the heck this is happening. there are only > 2 references to some controller code on lines 123 and 110 which are > > 110: render :update do |page| > > 123: done_responses.each do |r| > > if anyone has any idea on what might be happening, we would truly appreciate it. > > Chris > _______________________________________________ > 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 hughes.james at gmail.com Fri Nov 3 17:57:25 2006 From: hughes.james at gmail.com (James Hughes) Date: Fri, 3 Nov 2006 14:57:25 -0800 Subject: [Backgroundrb-devel] tasks need --rakelibdir Message-ID: <765a2c230611031457kc467141m394c9a80ec17e6a8@mail.gmail.com> Hey, quick question: what am I missing that I always need to pass the '--rakelibdir vendor/plugins/backgroundrb/tasks' option to rake? thanks, James From hughes.james at gmail.com Fri Nov 3 18:56:21 2006 From: hughes.james at gmail.com (James Hughes) Date: Fri, 3 Nov 2006 15:56:21 -0800 Subject: [Backgroundrb-devel] tasks need --rakelibdir In-Reply-To: <765a2c230611031457kc467141m394c9a80ec17e6a8@mail.gmail.com> References: <765a2c230611031457kc467141m394c9a80ec17e6a8@mail.gmail.com> Message-ID: <765a2c230611031556v695ee195m302bf9451e6e0ad6@mail.gmail.com> Sorry, appalling lack of detail there. This is with the new 0.20, but it's happened pre-0.20 as well. Without specifying the libdir I get the "Don't know how to build task 'backgroundrb:start'" message. This is with edge rails, rake version 0.7.1 on a fresh ubuntu edgy install. The case with pre 0.2 is on a redhat box, I don't have access to it so not sure of the particulars. thanks, jh On 11/3/06, James Hughes wrote: > Hey, > quick question: what am I missing that I always need to pass the > '--rakelibdir vendor/plugins/backgroundrb/tasks' option to rake? > > thanks, > James > From ezmobius at gmail.com Fri Nov 3 21:19:47 2006 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Fri, 3 Nov 2006 18:19:47 -0800 Subject: [Backgroundrb-devel] tasks need --rakelibdir In-Reply-To: <765a2c230611031556v695ee195m302bf9451e6e0ad6@mail.gmail.com> References: <765a2c230611031457kc467141m394c9a80ec17e6a8@mail.gmail.com> <765a2c230611031556v695ee195m302bf9451e6e0ad6@mail.gmail.com> Message-ID: Hi~ On Nov 3, 2006, at 3:56 PM, James Hughes wrote: > Sorry, appalling lack of detail there. > > This is with the new 0.20, but it's happened pre-0.20 as well. Without > specifying the libdir I get the "Don't know how to build task > 'backgroundrb:start'" message. This is with edge rails, rake version > 0.7.1 on a fresh ubuntu edgy install. The case with pre 0.2 is on a > redhat box, I don't have access to it so not sure of the particulars. > > thanks, > jh > > On 11/3/06, James Hughes wrote: >> Hey, >> quick question: what am I missing that I always need to pass the >> '--rakelibdir vendor/plugins/backgroundrb/tasks' option to rake? >> >> thanks, >> James >> > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > Hrmm. That is strange. I have never had to specify the rake lib dir. As long as you are in RAILS_ROOT rake should pick up any tasks within plugins tasks directory. Sorry I don't have a better answer for you. -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From gethemant at gmail.com Sat Nov 4 20:50:20 2006 From: gethemant at gmail.com (hemant) Date: Sun, 5 Nov 2006 07:20:20 +0530 Subject: [Backgroundrb-devel] backgroundrb preview Message-ID: Hi Ezra/skaar, Wow man, the exercise was worth it. The connection closed problem with socket as i mentioned in my earlier mails...completely disappeared, and now i can connect only once to the socket and keep reading..till end of its days. Literally impossible with older release of backgroundrb. This could also potentially solve the issues people were having with ActiveRecord. As i said somewhere in past, I was/am using my home baked solution with EventMachine and Memcache..which was serving me fine. But parsing the input data from socket is real pain. Parsing strings...are fun, but I had no idea..how do i go abt objects. But this release of backgroundrb fills the gap. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. From gethemant at gmail.com Sat Nov 4 21:19:21 2006 From: gethemant at gmail.com (hemant) Date: Sun, 5 Nov 2006 07:49:21 +0530 Subject: [Backgroundrb-devel] backgroundrb preview In-Reply-To: References: Message-ID: On 11/5/06, hemant wrote: > Hi Ezra/skaar, > > Wow man, the exercise was worth it. The connection closed problem with > socket as i mentioned in my earlier mails...completely disappeared, > and now i can connect only once to the socket and keep reading..till > end of its days. > > Literally impossible with older release of backgroundrb. > > This could also potentially solve the issues people were having with > ActiveRecord. > > As i said somewhere in past, I was/am using my home baked solution > with EventMachine and Memcache..which was serving me fine. But > parsing the input data from socket is real pain. Parsing strings...are > fun, but I had no idea..how do i go abt objects. > > But this release of backgroundrb fills the gap. > Here are some doubts/questions: I have a worker like: class FooWorker < BackgrounDRb::Worker::RailsBase attr_accessor :data_ready attr_accessor :xml_data def do_work @data_ready = false # initialize socket and few other things end def read_from_socket @data_ready = false # long running operation, may take time # populate XML data, read from socket @data_ready = true end Now..in controller: MiddleMan.new_worker(:class => :foobar_worker, :job_key => :lol, :args => "Lol") worker = MiddleMan.worker(:lol) worker.read_from_socket ##### interesting line #666 if worker.data_ready render :xml => worker.xml_data else render :text => "Worki going on" end now..on #666, how do i make sure..that controller just triggers the method in worker and control comes back to the controller immediately. Sounds like a typical use case of threads. What I would like to do, is poll on the worker if data is ready..or else display some foobar. Pretty standard thing i guess. Another question, if you guys are still dozing: Line # 443, README: "Schedule worker to trigger every minute on the fifth second. Make sure to delete these when they are done doing their work, as it would create a new worker with a generated key every time the schedule is triggered." So let's say..i have setup a perpetually running job that runs every 20 minutes or so, throguh this config: simple_label3: | :class: :example_worker | :job_key: :job_key3 | :worker_method: :do_work | :trigger_args: | :repeat_interval: 10.minute Now..why on earth, I should delete this worker..once it finishes processing at the end of each cycle? Surely..i am missing something or is that the case...or else I will have a basket full of workers doing same job over and over again..until earth tips over. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. From skaar at waste.org Sat Nov 4 22:19:05 2006 From: skaar at waste.org (skaar) Date: Sat, 4 Nov 2006 21:19:05 -0600 Subject: [Backgroundrb-devel] backgroundrb preview In-Reply-To: References: Message-ID: <20061105031905.GA27827@waste.org> > worker.read_from_socket ##### interesting line #666 > > now..on #666, how do i make sure..that controller just triggers the > method in worker and control comes back to the controller immediately. > Sounds like a typical use case of threads. it's not yet documented, but used internally for do_work, but you could call: worker.work_thread(:method => :read_from_socket) which will run the method in a separate thread in the worker process. (I would have to werify how work_thread behaves without arguments, but we can deal with that - please submit a ticket if you find that it doesn't work). > simple_label3: > | :class: :example_worker > | :job_key: :job_key3 > | :worker_method: :do_work > | :trigger_args: > | :repeat_interval: 10.minute > > Now..why on earth, I should delete this worker..once it finishes > processing at the end of each cycle? Surely..i am missing something or > is that the case...or else I will have a basket full of workers doing > same job over and over again..until earth tips over. in the example above you would not have this problem, nor a reason to delete the worker. You are using :job_key here, which means singleton worker. It's primarily in cases where you _don't_ specify the job_key that you have to look out for "spurious" workers. /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 gethemant at gmail.com Sun Nov 5 13:59:06 2006 From: gethemant at gmail.com (hemant) Date: Mon, 6 Nov 2006 00:29:06 +0530 Subject: [Backgroundrb-devel] backgroundrb preview In-Reply-To: <20061105031905.GA27827@waste.org> References: <20061105031905.GA27827@waste.org> Message-ID: On 11/5/06, skaar wrote: > > worker.read_from_socket ##### interesting line #666 > > > > now..on #666, how do i make sure..that controller just triggers the > > method in worker and control comes back to the controller immediately. > > Sounds like a typical use case of threads. > > it's not yet documented, but used internally for do_work, but you could > call: > > worker.work_thread(:method => :read_from_socket) > > which will run the method in a separate thread in the worker process. (I > would have to werify how work_thread behaves without arguments, but we > can deal with that - please submit a ticket if you find that it doesn't > work). > > > simple_label3: > > | :class: :example_worker > > | :job_key: :job_key3 > > | :worker_method: :do_work > > | :trigger_args: > > | :repeat_interval: 10.minute > > > > Now..why on earth, I should delete this worker..once it finishes > > processing at the end of each cycle? Surely..i am missing something or > > is that the case...or else I will have a basket full of workers doing > > same job over and over again..until earth tips over. > > in the example above you would not have this problem, nor a reason to > delete the worker. You are using :job_key here, which means singleton > worker. It's primarily in cases where you _don't_ specify the job_key > that you have to look out for "spurious" workers. > > /skaar The cloud has cleared...I can see clear blue sky. Days of slavery has just begun. Thanks PS: Can we have a mirror of backgroundrb SVN at rubyforge also? devjavu SVN doesn't play nice with people behind proxies. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. From skaar at waste.org Sun Nov 5 20:21:40 2006 From: skaar at waste.org (skaar) Date: Sun, 5 Nov 2006 19:21:40 -0600 Subject: [Backgroundrb-devel] backgroundrb preview In-Reply-To: <20061105031905.GA27827@waste.org> References: <20061105031905.GA27827@waste.org> Message-ID: <20061106012140.GA11325@waste.org> * skaar (skaar at waste.org) [061104 21:38]: > > worker.read_from_socket ##### interesting line #666 > > > > now..on #666, how do i make sure..that controller just triggers the > > method in worker and control comes back to the controller immediately. > > Sounds like a typical use case of threads. > > it's not yet documented, but used internally for do_work, but you could > call: > > worker.work_thread(:method => :read_from_socket) > > which will run the method in a separate thread in the worker process. (I > would have to werify how work_thread behaves without arguments, but we > can deal with that - please submit a ticket if you find that it doesn't > work). ok, the above will in 0.2.1 (and from trunk r142) work as adverticed, you can use work_thread to background in the worker any method, with or without arguments. For now you will have to device a way in the worker to determine when the method is done doing it's work. Worker exceptions are logged in backgroundrb.log. There is currently little indication in the MiddleMan if an exception has occured in the worker, but in the case an exception occur, the worker will be deleted. /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 gethemant at gmail.com Mon Nov 6 00:25:48 2006 From: gethemant at gmail.com (hemant) Date: Mon, 6 Nov 2006 10:55:48 +0530 Subject: [Backgroundrb-devel] backgroundrb preview In-Reply-To: <20061106012140.GA11325@waste.org> References: <20061105031905.GA27827@waste.org> <20061106012140.GA11325@waste.org> Message-ID: On 11/6/06, skaar wrote: > * skaar (skaar at waste.org) [061104 21:38]: > > > worker.read_from_socket ##### interesting line #666 > > > > > > now..on #666, how do i make sure..that controller just triggers the > > > method in worker and control comes back to the controller immediately. > > > Sounds like a typical use case of threads. > > > > it's not yet documented, but used internally for do_work, but you could > > call: > > > > worker.work_thread(:method => :read_from_socket) > > > > which will run the method in a separate thread in the worker process. (I > > would have to werify how work_thread behaves without arguments, but we > > can deal with that - please submit a ticket if you find that it doesn't > > work). > > ok, the above will in 0.2.1 (and from trunk r142) work as adverticed, > you can use work_thread to background in the worker any method, with or > without arguments. > > For now you will have to device a way in the worker to determine when > the method is done doing it's work. > > Worker exceptions are logged in backgroundrb.log. There is currently > little indication in the MiddleMan if an exception has occured in the > worker, but in the case an exception occur, the worker will be deleted. no problem..I have an instance variable..that takes care... if the worker has finished its execution. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. From gethemant at gmail.com Mon Nov 6 22:40:46 2006 From: gethemant at gmail.com (hemant) Date: Tue, 7 Nov 2006 09:10:46 +0530 Subject: [Backgroundrb-devel] start a worker when bdrb starts Message-ID: I am sure..again I am missing something, but I am trying to start a worker, when backgroundrb starts and it doesn't seem to work. Here is my config/backgroundrb_schedules.yml file: feed_worker: class: feed_worker job_key: feed_worker_key worker_method: do_work trigger_args: repeat_interval: 20.minutes I even tried this from Rails controller: # def start_feed_worker # begin # MiddleMan.schedule_worker(:class => :feed_worker, # :args => "foobar", # :job_key => :feed_worker_key, # :trigger_args => { # :repeat_interval => 30.minutes # }) # rescue # logger.info "Failed to start feed worker" # end # end doesn't seem to work again... Any ideas folks? -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. From skaar at waste.org Mon Nov 6 23:43:10 2006 From: skaar at waste.org (skaar) Date: Mon, 6 Nov 2006 22:43:10 -0600 Subject: [Backgroundrb-devel] start a worker when bdrb starts In-Reply-To: References: Message-ID: <20061107044310.GA22269@waste.org> * hemant (gethemant at gmail.com) [061106 22:32]: > I am sure..again I am missing something, but I am trying to start a > worker, when backgroundrb starts and it doesn't seem to work. > > Here is my config/backgroundrb_schedules.yml file: > > feed_worker: > class: feed_worker > job_key: feed_worker_key > worker_method: do_work > trigger_args: > repeat_interval: 20.minutes try to use symbols and to specify a start time: feed_worker: :class: :feed_worker :job_key: :feed_worker_key :worker_method: :do_work :trigger_args: :start: <%= Time.now %> :repeat_interval: <%= 20*60*60 %> /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 gethemant at gmail.com Mon Nov 6 23:58:05 2006 From: gethemant at gmail.com (hemant) Date: Tue, 7 Nov 2006 10:28:05 +0530 Subject: [Backgroundrb-devel] start a worker when bdrb starts In-Reply-To: <20061107044310.GA22269@waste.org> References: <20061107044310.GA22269@waste.org> Message-ID: On 11/7/06, skaar wrote: > * hemant (gethemant at gmail.com) [061106 22:32]: > > I am sure..again I am missing something, but I am trying to start a > > worker, when backgroundrb starts and it doesn't seem to work. > > > > Here is my config/backgroundrb_schedules.yml file: > > > > feed_worker: > > class: feed_worker > > job_key: feed_worker_key > > worker_method: do_work > > trigger_args: > > repeat_interval: 20.minutes > > try to use symbols and to specify a start time: > > feed_worker: > :class: :feed_worker > :job_key: :feed_worker_key > :worker_method: :do_work > :trigger_args: > :start: <%= Time.now %> > :repeat_interval: <%= 20*60*60 %> Ok..skaar, I did a exact copy paste of your config to backgroundrb_schedules.yml and here is my poor worker: require 'rss/2.0' require 'open-uri' class FeedWorker < BackgrounDRb::Worker::RailsBase def do_work(args) # This method is called in it's own new thread when you # call new worker. args is set to :args #google_url = "http://news.google.com/news?ned=us&topic=b&output=rss" # bcc serves trash to this site #bbc_url = "http://newsrss.bbc.co.uk/rss/newsonline_world_edition/business/rss.xml" logger.info "Starting the Yahoo feed worker" yahoo_url = "http://finance.yahoo.com/rss/headline?s=" symbol_list = NasdaqSymbols.find_all() symbol_list.each do|sym| temp_sym = sym.symbol.strip temp_url = yahoo_url + temp_sym get_feeds(temp_url,temp_sym) end end protected def get_feeds(url,temp_sym) open(url) do |http| response = http.read result = RSS::Parser.parse(response,false) result.items.each_with_index do |item,i| begin title = item.title[0..99] link = item.link description = item.description pub_date = item.pubDate #check if the feed is there in db feed_data = YahooFeeds.find(:first,:conditions => ["title = ?",title]) next unless feed_data.nil? if feed = YahooFeeds.create(:title => title, :link => link, :description => description, :pub_date => pub_date, :symbol => temp_sym ) logger.info("Saved to #{temp_sym}") end rescue Exception => e logger.info("#{e.to_s}") end # end of exception handling end # end of results parsing end # end of do |http| end # end of get_feeds function end FeedWorker.register Still...it doesn't seem to work...the worker is not started. This I am telling because...nothing comes to log files. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. From eduardodmz at gmail.com Tue Nov 7 17:51:29 2006 From: eduardodmz at gmail.com (Eduardo Dominguez) Date: Tue, 7 Nov 2006 16:51:29 -0600 Subject: [Backgroundrb-devel] scheduled jobs with cron Message-ID: I'm very interested in using backgroundrb for running jobs every n minutes. The release notes say that this functionality is not yet ready via backgroundrb. But I wonder, can I call backgroundrb with a ruby script from cron ? I know I could create a cron job that calls lynx (or whatever) on a specific page that will call backgroundrb, but I want to know if there other "friendlier" ways to use backgroundrb with cron. Thanks! -- Lalo From jasonsydes at gmail.com Tue Nov 7 20:42:21 2006 From: jasonsydes at gmail.com (Jason Sydes) Date: Tue, 7 Nov 2006 17:42:21 -0800 Subject: [Backgroundrb-devel] 0.2.0 worker/slave creation Message-ID: We ran into some problems accessing a freshly created worker, and had to insert a sleep of 1 second to get it to work. It looks like Ezra and skaar already know this: from middleman.rb: # HACK: there is a race in the worker/slave creation, we # currently need to sleep between create. sleep 0.1 You might want to increase it to 1 second for those of us on slowly mac books. Thanks for all your hard work on backgroundrb, it's a beautiful piece of work! Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061107/3ba60fee/attachment.html From jfoxny at gmail.com Tue Nov 7 20:54:47 2006 From: jfoxny at gmail.com (Jason Fox) Date: Tue, 7 Nov 2006 20:54:47 -0500 Subject: [Backgroundrb-devel] New Backgroundrb Speed Issues? Message-ID: <6CA4BCA9-7C77-41F2-96FC-0F60B4164356@gmail.com> The new backgroundrb seemed to me to be markedly slower than the old one. So, I ran a "side-by-side" comparison test using a worker that I had written which parses a CSV file and loads the results into a database. The results? The latest version appears to take twice as long to run the same code as the previous version. Has anyone else experienced speed issues with the new version? Regards, Jason From tve at voneicken.com Tue Nov 7 21:05:21 2006 From: tve at voneicken.com (Thorsten von Eicken) Date: Tue, 07 Nov 2006 18:05:21 -0800 Subject: [Backgroundrb-devel] New Backgroundrb Speed Issues? In-Reply-To: <6CA4BCA9-7C77-41F2-96FC-0F60B4164356@gmail.com> References: <6CA4BCA9-7C77-41F2-96FC-0F60B4164356@gmail.com> Message-ID: <45513B61.7020302@voneicken.com> Well, it forks a new process for every worker, instead of just spawning a thread. That's not free, and the overall impact depends on how long your workers run. On the positive side, you can launch a "persistent" worker, and then start threads inside that worker from MiddleMan. So for short workers you can emulate the old behavior, and presumably performance. (Well, there's an additional IPC there.) Thorsten Jason Fox wrote: > The new backgroundrb seemed to me to be markedly slower than the old > one. So, I ran a "side-by-side" comparison test using a worker that > I had written which parses a CSV file and loads the results into a > database. The results? The latest version appears to take twice as > long to run the same code as the previous version. Has anyone else > experienced speed issues with the new version? > > Regards, > Jason > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > From skaar at waste.org Tue Nov 7 21:20:40 2006 From: skaar at waste.org (skaar) Date: Tue, 7 Nov 2006 20:20:40 -0600 Subject: [Backgroundrb-devel] New Backgroundrb Speed Issues? In-Reply-To: <6CA4BCA9-7C77-41F2-96FC-0F60B4164356@gmail.com> References: <6CA4BCA9-7C77-41F2-96FC-0F60B4164356@gmail.com> Message-ID: <20061108022040.GD28284@waste.org> * Jason Fox (jfoxny at gmail.com) [061107 19:54]: > The new backgroundrb seemed to me to be markedly slower than the old > one. So, I ran a "side-by-side" comparison test using a worker that > I had written which parses a CSV file and loads the results into a > database. The results? The latest version appears to take twice as > long to run the same code as the previous version. Has anyone else > experienced speed issues with the new version? there is more setup when you are creating a new worker now, but performance when that is done, shouldn't be any worse. What kind of difference are you seeing? /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 jfoxny at gmail.com Tue Nov 7 21:29:11 2006 From: jfoxny at gmail.com (Jason Fox) Date: Tue, 7 Nov 2006 21:29:11 -0500 Subject: [Backgroundrb-devel] New Backgroundrb Speed Issues? Message-ID: The working running under the old backgroundrb took approximately 14 seconds to complete its task. With the new worker it is taking 28 seconds to perform the same amount of work under the same conditions (i.e., database state, system load, etc.). I could attempt the test again with a larger file and see if the ratio holds. Thoughts? Regards, Jason On Nov 7, 2006, at 9:20 PM, skaar wrote: > * Jason Fox (jfoxny at gmail.com) [061107 19:54]: > >> The new backgroundrb seemed to me to be markedly slower than the old >> one. So, I ran a "side-by-side" comparison test using a worker that >> I had written which parses a CSV file and loads the results into a >> database. The results? The latest version appears to take twice as >> long to run the same code as the previous version. Has anyone else >> experienced speed issues with the new version? >> > > there is more setup when you are creating a new worker now, but > performance when that is done, shouldn't be any worse. What kind of > difference are you seeing? > > /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 ezmobius at gmail.com Tue Nov 7 21:37:42 2006 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Tue, 7 Nov 2006 18:37:42 -0800 Subject: [Backgroundrb-devel] New Backgroundrb Speed Issues? In-Reply-To: References: Message-ID: <4440DA62-2BB7-4EF2-A544-4F69976E6744@gmail.com> Jason are you starting a new worker each time you try this? Or do you have a long running worker you can call multiple times to do the same calculations? The new system does have more overhead for starting new workers. So it is better to design your system with a few core workers that always run and then you continue to call methods on these long workers. The old system may be faster in a few cases and thats fine if it still works for you. This new version is much more scalable. I need it to be able to handle a significant number of things that each require the power of their own ruby interpreter. You can easily run into issues with ruby's green threads in the old code. That said the new code is still teething. Like we said we will have a rock solid production version by 0.3.0. We appreciate people testing the new version and please file bug reports on the trac: http://backgroundrb.devjavu.com/ Thanks -Ezra On Nov 7, 2006, at 6:29 PM, Jason Fox wrote: > The working running under the old backgroundrb took approximately 14 > seconds to complete its task. With the new worker it is taking 28 > seconds to perform the same amount of work under the same conditions > (i.e., database state, system load, etc.). I could attempt the test > again with a larger file and see if the ratio holds. Thoughts? > > Regards, > Jason > > On Nov 7, 2006, at 9:20 PM, skaar wrote: > > >> * Jason Fox (jfoxny at gmail.com) [061107 19:54]: >> >>> The new backgroundrb seemed to me to be markedly slower than the old >>> one. So, I ran a "side-by-side" comparison test using a worker that >>> I had written which parses a CSV file and loads the results into a >>> database. The results? The latest version appears to take twice as >>> long to run the same code as the previous version. Has anyone else >>> experienced speed issues with the new version? >>> >> >> there is more setup when you are creating a new worker now, but >> performance when that is done, shouldn't be any worse. What kind of >> difference are you seeing? >> >> /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 >> --------------------------------------------------------------------- >> - >> > > > _______________________________________________ > 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 jfoxny at gmail.com Tue Nov 7 23:10:07 2006 From: jfoxny at gmail.com (Jason Fox) Date: Tue, 7 Nov 2006 23:10:07 -0500 Subject: [Backgroundrb-devel] New Backgroundrb Speed Issues? In-Reply-To: <4440DA62-2BB7-4EF2-A544-4F69976E6744@gmail.com> References: <4440DA62-2BB7-4EF2-A544-4F69976E6744@gmail.com> Message-ID: Here's what I did: - Started the old backgroundrb - Called the worker from my controller - Recorded the time (~14 seconds) - Shutdown the old backgroundrb - Started the new backgroundrb - Called the worker from my controller - Recorded the time (~28 seconds) So, basically, one call to each version right after starting them up. Regards, Jason On Nov 7, 2006, at 9:37 PM, Ezra Zygmuntowicz wrote: > Jason are you starting a new worker each time you try this? Or do > you have a long running worker you can call multiple times to do > the same calculations? The new system does have more overhead for > starting new workers. So it is better to design your system with a > few core workers that always run and then you continue to call > methods on these long workers. > > The old system may be faster in a few cases and thats fine if it > still works for you. This new version is much more scalable. I need > it to be able to handle a significant number of things that each > require the power of their own ruby interpreter. You can easily run > into issues with ruby's green threads in the old code. > > That said the new code is still teething. Like we said we will have > a rock solid production version by 0.3.0. We appreciate people > testing the new version and please file bug reports on the trac: > > http://backgroundrb.devjavu.com/ > > Thanks > -Ezra > > > On Nov 7, 2006, at 6:29 PM, Jason Fox wrote: > >> The working running under the old backgroundrb took approximately 14 >> seconds to complete its task. With the new worker it is taking 28 >> seconds to perform the same amount of work under the same conditions >> (i.e., database state, system load, etc.). I could attempt the test >> again with a larger file and see if the ratio holds. Thoughts? >> >> Regards, >> Jason >> >> On Nov 7, 2006, at 9:20 PM, skaar wrote: >> >> >>> * Jason Fox (jfoxny at gmail.com) [061107 19:54]: >>> >>>> The new backgroundrb seemed to me to be markedly slower than the >>>> old >>>> one. So, I ran a "side-by-side" comparison test using a worker >>>> that >>>> I had written which parses a CSV file and loads the results into a >>>> database. The results? The latest version appears to take >>>> twice as >>>> long to run the same code as the previous version. Has anyone else >>>> experienced speed issues with the new version? >>>> >>> >>> there is more setup when you are creating a new worker now, but >>> performance when that is done, shouldn't be any worse. What kind of >>> difference are you seeing? >>> >>> /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 >>> -------------------------------------------------------------------- >>> -- >>> >> >> >> _______________________________________________ >> 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 gethemant at gmail.com Tue Nov 7 23:27:35 2006 From: gethemant at gmail.com (hemant) Date: Wed, 8 Nov 2006 09:57:35 +0530 Subject: [Backgroundrb-devel] scheduled jobs with cron In-Reply-To: References: Message-ID: On 11/8/06, Eduardo Dominguez wrote: > I'm very interested in using backgroundrb for running jobs every n minutes. > > The release notes say that this functionality is not yet ready via > backgroundrb. But I wonder, can I call backgroundrb with a ruby script > from cron ? > > I know I could create a cron job that calls lynx (or whatever) on a > specific page that will call backgroundrb, but I want to know if there > other "friendlier" ways to use backgroundrb with cron. > > Thanks! This functionality is ready (AFAIK) in trunk version of bdrb...and i am already using it. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. From kimmo.lehto at gmail.com Thu Nov 9 03:38:28 2006 From: kimmo.lehto at gmail.com (Kimmo Lehto) Date: Thu, 9 Nov 2006 10:38:28 +0200 Subject: [Backgroundrb-devel] Making it work under JRuby Message-ID: I've been having problems starting the daemon under JRuby, has anyone else tried this? What I'm trying to accomplish is running Rails on regular ruby and BackgroundRB on JRuby. I'm working on a project that requires me to use a java-api to communicate with a service and it should work so that when a user logs on to the rails app, it actually authenticates through the java-api and the returned session object should stay alive while the user's browsing session stays alive and that is where BackgroundRB fits in. Suggestions for alternative approaches also appreciated. From skaar at waste.org Thu Nov 9 08:01:12 2006 From: skaar at waste.org (skaar) Date: Thu, 9 Nov 2006 07:01:12 -0600 Subject: [Backgroundrb-devel] Making it work under JRuby In-Reply-To: References: Message-ID: <20061109130112.GB6857@waste.org> * Kimmo Lehto (kimmo.lehto at gmail.com) [061109 04:05]: > I've been having problems starting the daemon under JRuby, has anyone > else tried this? the short answer is: /opt/jruby/bin/jirb irb(main):001:0> read, write = IO::pipe NoMethodError: undefined method `pipe' for IO:Class The slave library we are using, use pipes and domain sockets, which are not available with jruby. As with Windows - if someone where to implement a library with a similar interface to Slave, then it would be relatively straight forward for us to use this. What I was hoping we could get wourking, was to run the MiddleMan client part with JRuby, so that Rails on Ruby or ?ny other client code could communicate with a BackgrounDRb server. Right now this doesn't work either, and there is a jira bug for this: http://jira.codehaus.org/browse/JRUBY-248 to the extent we are tracking this, it will be in: http://backgroundrb.devjavu.com/projects/backgroundrb/ticket/25 /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 jasonsydes at gmail.com Thu Nov 9 14:29:18 2006 From: jasonsydes at gmail.com (Jason Sydes) Date: Thu, 9 Nov 2006 11:29:18 -0800 Subject: [Backgroundrb-devel] Multiple backgroundrb servers? Message-ID: What are people are doing when they need to deploy a new code base? You can't just restart backgroundrb, because then you lose any long-running backgroundrb processes. But then you'd conceivably have to wait several hours for all your procs to complete before pushing out the new code base. I was originally thinking that during code deploys, we'd start up a second backgroundrb server (on the new code base) and shunt all new jobs to it, and wait for all the existing jobs on the first backgroundrb server to complete before shutting the first one down. A flip-flop essentially. But then I realized that backgroundrb doesn't currently support multiple servers on a single rails installation. I noticed a ticket contemplating the use of Rinda for a future release, but wasn't sure if that implementation would address this scenario. I'm not sure if I'm missing something here, so I thought I'd write to the list and see if anyone had any thoughts. Thanks! Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061109/8d297032/attachment.html From scottd at gmail.com Fri Nov 10 16:43:28 2006 From: scottd at gmail.com (Scott Davies) Date: Fri, 10 Nov 2006 13:43:28 -0800 Subject: [Backgroundrb-devel] acls in 0.2.0? Message-ID: <75f591160611101343q1969ca2bjc9355423f33f075b@mail.gmail.com> Hi -- Just trying to get started with backgroundrb 0.2.0 after having glanced at an earlier version and thought "cool, I'll definitely need this later." I notice that the old sample config file has the following in it: acl: deny: all allow: localhost 127.0.0.1 order: deny,allow I'm not seeing this in the sample configuration in the current README, though, and I'm not seeing any documentation on config files other than that one example. The README mentions "some options are obsolete and will just be ignored", so I'm naturally hesitant to assume that if I add an acl to the current config file and it doesn't explode then I must be protected from external hackers. What's the deal with acls in 0.2.0, and is there any documentation for config files that I just haven't found yet? Thanks! -- Scott From skaar at waste.org Fri Nov 10 17:13:28 2006 From: skaar at waste.org (skaar) Date: Fri, 10 Nov 2006 16:13:28 -0600 Subject: [Backgroundrb-devel] acls in 0.2.0? In-Reply-To: <75f591160611101343q1969ca2bjc9355423f33f075b@mail.gmail.com> References: <75f591160611101343q1969ca2bjc9355423f33f075b@mail.gmail.com> Message-ID: <20061110221328.GA5713@waste.org> yes, sorry about that - I re-added it a little while ago in trunk and it will be in 0.2.1. Now effectively you can specify localhost as host, and the backgroundrb server will not be remotely accessable for now. Hope this helps. /skaar * Scott Davies (scottd at gmail.com) [061110 16:06]: > Hi -- > > Just trying to get started with backgroundrb 0.2.0 after having > glanced at an earlier version and thought "cool, I'll definitely need > this later." I notice that the old sample config file has the > following in it: > > acl: > deny: all > allow: localhost 127.0.0.1 > order: deny,allow > > I'm not seeing this in the sample configuration in the current README, > though, and I'm not seeing any documentation on config files other > than that one example. The README mentions "some options are obsolete > and will just be ignored", so I'm naturally hesitant to assume that if > I add an acl to the current config file and it doesn't explode then I > must be protected from external hackers. > > What's the deal with acls in 0.2.0, and is there any documentation for > config files that I just haven't found yet? > > Thanks! > > -- Scott > _______________________________________________ > 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 jasonsydes at gmail.com Fri Nov 10 17:32:27 2006 From: jasonsydes at gmail.com (Jason Sydes) Date: Fri, 10 Nov 2006 14:32:27 -0800 Subject: [Backgroundrb-devel] acls in 0.2.0? In-Reply-To: <75f591160611101343q1969ca2bjc9355423f33f075b@mail.gmail.com> References: <75f591160611101343q1969ca2bjc9355423f33f075b@mail.gmail.com> Message-ID: On 11/10/06, Scott Davies wrote: > What's the deal with acls in 0.2.0, and is there any documentation for > config files that I just haven't found yet? Hi Scott, It looks like it didn't make it into 0.2.0, but they've already added it back into the trunk: http://backgroundrb.devjavu.com/projects/backgroundrb/ticket/1 Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061110/cd40360a/attachment-0001.html From davidjy.lee at gmail.com Sat Nov 11 15:48:02 2006 From: davidjy.lee at gmail.com (David Lee) Date: Sat, 11 Nov 2006 15:48:02 -0500 Subject: [Backgroundrb-devel] how many processes? Message-ID: <338f29120611111248m65eba5b6ja5e6e0881b0ee52b@mail.gmail.com> Hello, I'm currently using backgroundrb to fetch feeds for an RSS aggregator. So as you can imagine, backgroundrb is a very critical piece of the app. I was wondering what a recommended pool size would be for this kind of application. Ideally, I'd like to have as many processes in the pool as possible, but what would be too many? Thank you, David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061111/f68ac5ac/attachment.html From ezmobius at gmail.com Sat Nov 11 16:15:32 2006 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Sat, 11 Nov 2006 13:15:32 -0800 Subject: [Backgroundrb-devel] how many processes? In-Reply-To: <338f29120611111248m65eba5b6ja5e6e0881b0ee52b@mail.gmail.com> References: <338f29120611111248m65eba5b6ja5e6e0881b0ee52b@mail.gmail.com> Message-ID: <69172F69-3FD0-4F53-A888-45C00C4C5362@brainspl.at> On Nov 11, 2006, at 12:48 PM, David Lee wrote: > Hello, > > I'm currently using backgroundrb to fetch feeds for an RSS > aggregator. So as you can imagine, backgroundrb is a very critical > piece of the app. I was wondering what a recommended pool size > would be for this kind of application. Ideally, I'd like to have as > many processes in the pool as possible, but what would be too many? > > Thank you, > David > Hey David- That really depends on the hardware and memory you have to use as well as the kind of traffic and throughput you need to handle. Are you using ActiveRecord models in the workers? If so each worker requires quite a bit of memory. Without using AR its only 1 or 2 MB per process. If you drag rails into the mix each rails base workers is 20Mb or so. The new version also has a slower startup time for spawning workers. So the best way to approach development with the new code is to run a number of named immortal workers that boot when you start backgroundrb. Then these workers can always be working or can be repeatedly called to do the same job over and over. So if you can do without ActiveRecord then you can run many processes. If each worker has to laod rails then it adds up quick and you should use fewer workers. I know AR is great convenience but loading all of rails to accces the database is a lot of overhead. It may be best to use the mysql ruby bindings directly to query or insert to the db. Then you still get db access but you can run a lot more workers since you don't have to load rails. But all in all I think somewhere around 10-20 workers that don't use AR can do a *ton* of work. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From davidjy.lee at gmail.com Sat Nov 11 18:40:35 2006 From: davidjy.lee at gmail.com (David Lee) Date: Sat, 11 Nov 2006 18:40:35 -0500 Subject: [Backgroundrb-devel] Error when creating a new worker -- "Text is not a module - (TypeError)" Message-ID: <338f29120611111540v7e54cd8r254bd9fb23026880@mail.gmail.com> Hello everyone, I'm stuck with this very obscure error whenever I try to create a new worker. My worker is a subclass of BackgrounDRb::Worker::RailsBase, and if you follow the stack trace below, you can tell that the error occurs while trying to load Rails. There is no problem starting up the server, by the way. Does anyone have any idea what might be causing this? I didn't have this problem with the previous version of backgroundrb. Any pointers would be appreciated. Thank you! David Text is not a module - (TypeError) /Users/guest/workspace/nano/config/../vendor/rails/actionmailer/lib/action_mailer/vendor/text/format.rb:49 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' /Users/guest/workspace/nano/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:147:in `require' /Users/guest/workspace/nano/config/../vendor/rails/actionmailer/lib/action_mailer/mail_helper.rb:1 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' /Users/guest/workspace/nano/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:147:in `require' /Users/guest/workspace/nano/config/../vendor/rails/actionmailer/lib/action_mailer.rb:39 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' /Users/guest/workspace/nano/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:147:in `require' /Users/guest/workspace/nano/config/../vendor/rails/railties/lib/initializer.rb:137:in `require_frameworks' /Users/guest/workspace/nano/config/../vendor/rails/railties/lib/initializer.rb:137:in `require_frameworks' /Users/guest/workspace/nano/config/../vendor/rails/railties/lib/initializer.rb:81:in `process' /Users/guest/workspace/nano/config/../vendor/rails/railties/lib/initializer.rb:42:in `run' /Users/guest/workspace/nano/config/environment.rb:13 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' /Users/guest/workspace/nano/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:147:in `require' /Users/guest/workspace/nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker_rails.rb:19:in `initialize' /Users/guest/workspace/nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:170:in `new_worker' /Users/guest/workspace/nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch' /Users/guest/workspace/nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `dispatch' /Users/guest/workspace/nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:159:in `new_worker' /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' /Users/guest/workspace/nano/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:215:in `run' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in `start_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:196:in `start_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:226:in `start' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/controller.rb:72:in `run' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in `run_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in `catch_exceptions' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:178:in `run_proc' /Users/guest/workspace/nano/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:204:in `run' ./script/backgroundrb:29 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061111/1c158d41/attachment.html From hughes.james at gmail.com Wed Nov 15 15:48:53 2006 From: hughes.james at gmail.com (James Hughes) Date: Wed, 15 Nov 2006 12:48:53 -0800 Subject: [Backgroundrb-devel] 0.2.0 worker/slave creation In-Reply-To: References: Message-ID: <765a2c230611151248i4483d7bg9aa7aaf22314c5f7@mail.gmail.com> Hi, I'm seeing "Starting WorkerLogger" in the log, but no ResultsLogger. Subsequently, when I assign to the results hash in my worker it disappears into neverland. Could this be the problem I'm experiencing? thanks, James On 11/7/06, Jason Sydes wrote: > We ran into some problems accessing a freshly created worker, and had to > insert a sleep of 1 second to get it to work. It looks like Ezra and skaar > already know this: > > from middleman.rb: > # HACK: there is a race in the worker/slave creation, we > # currently need to sleep between create. > sleep 0.1 > > You might want to increase it to 1 second for those of us on slowly mac > books. > > Thanks for all your hard work on backgroundrb, it's a beautiful piece of > work! > > Jason > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > From jasonsydes at gmail.com Wed Nov 15 21:03:56 2006 From: jasonsydes at gmail.com (Jason Sydes) Date: Wed, 15 Nov 2006 18:03:56 -0800 Subject: [Backgroundrb-devel] 0.2.0 worker/slave creation In-Reply-To: <765a2c230611151248i4483d7bg9aa7aaf22314c5f7@mail.gmail.com> References: <765a2c230611151248i4483d7bg9aa7aaf22314c5f7@mail.gmail.com> Message-ID: On 11/15/06, James Hughes wrote: > I'm seeing "Starting WorkerLogger" in the log, but no ResultsLogger. > Subsequently, when I assign to the results hash in my worker it > disappears into neverland. Could this be the problem I'm experiencing? > Maaaybe. The Results and Logger workers get started when you start backgroundrb w/ "script/backgroundrb start", long before you create a new worker (or even start rails). Then again, the Results and Logger workers are mostly just regular workers that get initialized the same way as other workers, so they may be getting 'lost' in the same way? Not sure! You may want to try the 'end.join' fix that skaar just checked in ( http://backgroundrb.devjavu.com/projects/backgroundrb/changeset/154), which I believe should fix at least the problem I originally described: In vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb, just change the closing 'end' of the '@thread_pool.dispatch do' block to ' end.join'. You're not seeing "In ResultsWorker" in backgroundrb.log. Are you using release-0.2.0, or are you working from the trunk? What do you see when you do ps aux |grep backgroundrb ? Maybe you're assigning to the results hash incorrectly? If you're doing something like the following, it won't work (see the README): results[:other_key] = [] results[:other_key] << "add to key" Jason On 11/7/06, Jason Sydes wrote: > > We ran into some problems accessing a freshly created worker, and had to > > insert a sleep of 1 second to get it to work. It looks like Ezra and > skaar > > already know this: > > > > from middleman.rb: > > # HACK: there is a race in the worker/slave creation, we > > # currently need to sleep between create. > > sleep 0.1 > > > > You might want to increase it to 1 second for those of us on slowly mac > > books. > > > > Thanks for all your hard work on backgroundrb, it's a beautiful piece of > > work! > > > > Jason > > > > _______________________________________________ > > 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/20061115/6ae9a85a/attachment.html From hughes.james at gmail.com Wed Nov 15 23:01:41 2006 From: hughes.james at gmail.com (James Hughes) Date: Wed, 15 Nov 2006 20:01:41 -0800 Subject: [Backgroundrb-devel] 0.2.0 worker/slave creation In-Reply-To: References: <765a2c230611151248i4483d7bg9aa7aaf22314c5f7@mail.gmail.com> Message-ID: <765a2c230611152001r1a260e2bp3fcfabaced103622@mail.gmail.com> On 11/15/06, Jason Sydes wrote: > On 11/15/06, James Hughes wrote: > > > I'm seeing "Starting WorkerLogger" in the log, but no ResultsLogger. > > Subsequently, when I assign to the results hash in my worker it > > disappears into neverland. Could this be the problem I'm experiencing? > > > You're not seeing "In ResultsWorker" in backgroundrb.log. Are you using > release-0.2.0, or are you working from the trunk? What do you see when you > do > ps aux |grep backgroundrb > ? I'm on 0.2.0 but I was thinking of switching to trunk. I am seeing the results worker in ps. Wierd that the logger would announce it's presence and not the results worker. > > Maybe you're assigning to the results hash incorrectly? If you're doing > something like the following, it won't work (see the README): > results[:other_key] = [] > results[:other_key] << "add to key" > Yeh, it's when I assign to it that it disappears. I'll look into this a bit more. thanks, James From cremes.devlist at mac.com Thu Nov 16 08:01:56 2006 From: cremes.devlist at mac.com (cremes.devlist at mac.com) Date: Thu, 16 Nov 2006 07:01:56 -0600 Subject: [Backgroundrb-devel] test unit approach? Message-ID: I'm just getting back to looking at backgroundrb after a long hiatus since June. I'm looking at creating some workers but I'm a bit stuck as to how I should write tests for them. What's the recommended approach for unit testing of workers? The project will ultimately be used by a Rails app but I'm comfortable developing the worker code as a standalone in the beginning. Any suggestions or examples? cr From skaar at waste.org Thu Nov 16 09:38:13 2006 From: skaar at waste.org (skaar) Date: Thu, 16 Nov 2006 08:38:13 -0600 Subject: [Backgroundrb-devel] test unit approach? In-Reply-To: References: Message-ID: <20061116143812.GD24788@waste.org> * cremes.devlist at mac.com (cremes.devlist at mac.com) [061116 08:10]: > I'm just getting back to looking at backgroundrb after a long hiatus > since June. I'm looking at creating some workers but I'm a bit stuck > as to how I should write tests for them. What's the recommended > approach for unit testing of workers? We have at this point not worked out how unittest/specs are going to work. At this point we've even disabled the unit test output in the worker generator for 0.2.1. There is two approaches: 1) fire up a backgroundrb server and run worker unittest against that, 2) mock the server side middleman and just test the logic of the worker class. We'll probably end up with a combination of this. It is of course up for grabs if someone feel like spending time on it :) /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 cremes.devlist at mac.com Thu Nov 16 10:04:36 2006 From: cremes.devlist at mac.com (cremes.devlist at mac.com) Date: Thu, 16 Nov 2006 07:04:36 -0800 Subject: [Backgroundrb-devel] test unit approach? In-Reply-To: <20061116143812.GD24788@waste.org> References: <20061116143812.GD24788@waste.org> Message-ID: On Thursday, November 16, 2006, at 08:47AM, "skaar" wrote: >* cremes.devlist at mac.com (cremes.devlist at mac.com) [061116 08:10]: >> I'm just getting back to looking at backgroundrb after a long hiatus >> since June. I'm looking at creating some workers but I'm a bit stuck >> as to how I should write tests for them. What's the recommended >> approach for unit testing of workers? > >We have at this point not worked out how unittest/specs are going to >work. At this point we've even disabled the unit test output in the >worker generator for 0.2.1. > >There is two approaches: 1) fire up a backgroundrb server and run worker >unittest against that, 2) mock the server side middleman and just test >the logic of the worker class. We'll probably end up with a combination >of this. It is of course up for grabs if someone feel like spending time >on it :) I like approach #2. If I can extract something useful from my work, I'll donate it to the project. cr From hughes.james at gmail.com Thu Nov 16 16:49:12 2006 From: hughes.james at gmail.com (James Hughes) Date: Thu, 16 Nov 2006 13:49:12 -0800 Subject: [Backgroundrb-devel] Assigning to results - missing something Message-ID: <765a2c230611161349q75248554le8f0e7bfe5457f4f@mail.gmail.com> Hi, I'm trying to convert an app to use 0.2.0, and having a little trouble understanding how to use the results hash. Formerly my worker had an instance variable, @file_stats which was initialized to an empty hash; I have replaced @file_stats with results[:file_hash]. Actually my initial pass at this was just to do a s/@file_stats/results[:file_hash]/. Which gets me the following: results[:file_stats] = {} logger.debug " Generating checksum for #{path}..." results[:file_stats][path][:checksum] = Digest::MD5.hexdigest(File.read(path)) logger.debug " ...done" logger.debug " Getting file size for #{path}..." results[:file_stats][path][:size] = File.size(path) logger.debug results[:file_stats][path][:size] So as soon as I attempt the checksum assignment above, bgrb disappears. I see the 'generating checksum' message, but it never says '...done'. Jason Sydes has intimated to me in another thread that I can't do what I'm attempting above. But a hash is a hash is a hash, right? Or is it? James ps. I initially thought this was an issue with the results worker not starting properly as it doesn't announce it's presence in the log. But I'm seeing it in the process list, so I assume I can discount that possibility. From eimorton at gmail.com Fri Nov 17 10:23:51 2006 From: eimorton at gmail.com (Erik Morton) Date: Fri, 17 Nov 2006 10:23:51 -0500 Subject: [Backgroundrb-devel] Multiple backgroundrb servers? In-Reply-To: References: Message-ID: I have concerns about deploying code with BackgroundRB processes running as well. Though I haven't looked into the code yet to see if there is a way to cut off all new requests to wait for existing processes to finish before deploying. Have you had any additional thoughts on this? Regards, Erik On Nov 9, 2006, at 2:29 PM, Jason Sydes wrote: > What are people are doing when they need to deploy a new code > base? You can't just restart backgroundrb, because then you lose > any long-running backgroundrb processes. But then you'd > conceivably have to wait several hours for all your procs to > complete before pushing out the new code base. > > I was originally thinking that during code deploys, we'd start up a > second backgroundrb server (on the new code base) and shunt all new > jobs to it, and wait for all the existing jobs on the first > backgroundrb server to complete before shutting the first one > down. A flip-flop essentially. > > But then I realized that backgroundrb doesn't currently support > multiple servers on a single rails installation. I noticed a > ticket contemplating the use of Rinda for a future release, but > wasn't sure if that implementation would address this scenario. > > I'm not sure if I'm missing something here, so I thought I'd write > to the list and see if anyone had any thoughts. > > Thanks! > Jason > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel From skaar at waste.org Fri Nov 17 11:19:46 2006 From: skaar at waste.org (skaar) Date: Fri, 17 Nov 2006 10:19:46 -0600 Subject: [Backgroundrb-devel] Assigning to results - missing something In-Reply-To: <765a2c230611161349q75248554le8f0e7bfe5457f4f@mail.gmail.com> References: <765a2c230611161349q75248554le8f0e7bfe5457f4f@mail.gmail.com> Message-ID: <20061117161946.GA19471@waste.org> * James Hughes (hughes.james at gmail.com) [061117 08:47]: > Hi, > > I'm trying to convert an app to use 0.2.0, and having a little trouble > understanding how to use the results hash. > > Formerly my worker had an instance variable, @file_stats which was > initialized to an empty hash; I have replaced @file_stats with > results[:file_hash]. Actually my initial pass at this was just to do a > s/@file_stats/results[:file_hash]/. Which gets me the following: > > results[:file_stats] = {} > logger.debug " Generating checksum for #{path}..." > results[:file_stats][path][:checksum] = > Digest::MD5.hexdigest(File.read(path)) > logger.debug " ...done" > logger.debug " Getting file size for #{path}..." > results[:file_stats][path][:size] = File.size(path) > logger.debug results[:file_stats][path][:size] give this a try: file_stats = {} checksum = Digest::MD5.hexdigest(File.read(path)) file_stats[path][:checksum] = checksum results[:file_stats] = file_stats It's not quite a regular hash. The results method returns a hash, which include the current data for the particular worker. We then inject a singleton override for assignment on the top level hash key, so that when you do assignment, this will be sent to the results worker and merged with the results data for the worker. It might be possible to do the same with values (including sub hashes), but then you loose a lot of visibility, since objects with singleton methods don't de/serialize easily - this is why you need to call #to_hash on results to actually see the data. We might find a better way to do this in a later release. For now you just have to live with temporary nested hashes, which you assign directly to results[:key]. This is documented in the README in trunk. /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 jodi at nNovation.ca Mon Nov 20 10:17:30 2006 From: jodi at nNovation.ca (Jodi Showers) Date: Mon, 20 Nov 2006 10:17:30 -0500 Subject: [Backgroundrb-devel] Multiple backgroundrb servers? In-Reply-To: References: Message-ID: <91C2D48A-D51D-40BA-85F1-8B0F5AE728B8@nNovation.ca> In the past I developed a similar system to backgroundRB that used java spaces. We'd submit jobs to the space process, and then workers would pull jobs from the space. Using that architecture processes could be upgraded, without impacting jobs, jobs dispatching - (incidentally sing multiple rinda spaces, is very useful for testing). Ez, You were speaking once about Rinda. Is that still a consideration? lurker Jodi. On 17-Nov-06, at 10:23 AM, Erik Morton wrote: > I have concerns about deploying code with BackgroundRB processes > running as well. Though I haven't looked into the code yet to see if > there is a way to cut off all new requests to wait for existing > processes to finish before deploying. Have you had any additional > thoughts on this? > > Regards, > Erik > On Nov 9, 2006, at 2:29 PM, Jason Sydes wrote: > >> What are people are doing when they need to deploy a new code >> base? You can't just restart backgroundrb, because then you lose >> any long-running backgroundrb processes. But then you'd >> conceivably have to wait several hours for all your procs to >> complete before pushing out the new code base. >> >> I was originally thinking that during code deploys, we'd start up a >> second backgroundrb server (on the new code base) and shunt all new >> jobs to it, and wait for all the existing jobs on the first >> backgroundrb server to complete before shutting the first one >> down. A flip-flop essentially. >> >> But then I realized that backgroundrb doesn't currently support >> multiple servers on a single rails installation. I noticed a >> ticket contemplating the use of Rinda for a future release, but >> wasn't sure if that implementation would address this scenario. >> >> I'm not sure if I'm missing something here, so I thought I'd write >> to the list and see if anyone had any thoughts. >> >> Thanks! >> Jason >> _______________________________________________ >> 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 davidjy.lee at gmail.com Mon Nov 20 16:06:01 2006 From: davidjy.lee at gmail.com (David Lee) Date: Mon, 20 Nov 2006 16:06:01 -0500 Subject: [Backgroundrb-devel] Passing object into results - "can't convert DRb::DRbUnknown into Hash - (TypeError)" Message-ID: <338f29120611201306j3059015cw9951197c48c1cfdf@mail.gmail.com> Hi, I'm using backgroundrb to get RSS feeds and pass them back to the controller. I'm using the Ruby RSS library to parse the feed, which returns an RSS object. After that I pass the object into the results hash, but that's when this error occurs. Basically, this is what I have: rss = RSS::Parser.parse(response.body) results[:feed] = rss # error! 20061120-15:46:19 (16250) (drbunix:///tmp/backgroundrb.16249/backgroundrb_results_0) /Users/guest/workspace/project_nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:101:in `merge!' 20061120-15:46:19 (16250) (drbunix:///tmp/backgroundrb.16249/backgroundrb_results_0) /Users/guest/workspace/project_nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:101:in `set_result' Any ideas? Thank you, David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061120/4856084a/attachment.html From davidjy.lee at gmail.com Mon Nov 20 18:08:35 2006 From: davidjy.lee at gmail.com (David Lee) Date: Mon, 20 Nov 2006 18:08:35 -0500 Subject: [Backgroundrb-devel] Passing object into results - "can't convert DRb::DRbUnknown into Hash - (TypeError)" In-Reply-To: <20061120224222.GB14523@waste.org> References: <338f29120611201306j3059015cw9951197c48c1cfdf@mail.gmail.com> <20061120224222.GB14523@waste.org> Message-ID: <338f29120611201508y75f68a27yfc41ae9a8cf61a3@mail.gmail.com> skaar, Thank you. That works :) On 11/20/06, skaar wrote: > > * David Lee (davidjy.lee at gmail.com) [061120 15:45]: > > Hi, > > > > I'm using backgroundrb to get RSS feeds and pass them back to the > > controller. I'm using the Ruby RSS library to parse the feed, which > > returns an RSS object. After that I pass the object into the results > hash, > > but that's when this error occurs. Basically, this is what I have: > > > > rss = RSS::Parser.parse(response.body) > > results[:feed] = rss # error! > > > > 20061120-15:46:19 (16250) > > (drbunix:///tmp/backgroundrb.16249/backgroundrb_results_0) > > > /Users/guest/workspace/project_nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:101:in > > `merge!' > > 20061120-15:46:19 (16250) > > (drbunix:///tmp/backgroundrb.16249/backgroundrb_results_0) > > > /Users/guest/workspace/project_nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:101:in > > `set_result' > > > > Any ideas? > > it would seem like parse returns data that is not serializable over DRb > from the perspective of the results worker. > > I need to think a little bit how to go about with this. I don't think we > want the results worker to load all possible libraries that the workers > are using. In this case, if we just add require 'rss' to the results > worker it will work. > > Then if you run from the console, you would also have to add a require > 'rss' to display the data properly. > > I've captured a simple case in: > http://backgroundrb.devjavu.com/projects/backgroundrb/changeset/158 > > /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/20061120/8081cd5e/attachment-0001.html From eduardodmz at gmail.com Mon Nov 20 18:21:02 2006 From: eduardodmz at gmail.com (Eduardo Dominguez) Date: Mon, 20 Nov 2006 17:21:02 -0600 Subject: [Backgroundrb-devel] schedule support on latest svn, a question Message-ID: I'm running the latest backgroundrb mainly for scheduled tasks support. As per the documentation I created the backgroundrb_schedules.yml with the following: simple_label: :class: :document_sorter_worker :worker_method: :do_work :job: :bleh :trigger_args: :start: <%= Time.now + 5.seconds %> :end: <%= Time.now + 10.minutes :repeat_interval: 1.minute Under lib/workers I have the following class: class DocumentSorterWorker < BackgrounDRb::Worker::RailsBase def do_work(args) logger.info('DocumentSorterWorker do work') results[:do_work_time] = Time.now.to_s results[:done_with_do_work] ||= true end end DocumentSorterWorker.register Basically does nothing but log that it's running. After running "script/server run" this is what I have in backgroundrb_server.log: 20061120-17:04:52 (31960) port: 2000 20061120-17:04:52 (31960) worker_dir: /home/ed/Documents/test/lib/workers 20061120-17:04:52 (31960) protocol: drbunix 20061120-17:04:52 (31960) uri: drbunix:///tmp/backgroundrbunix_localhost_2000 20061120-17:04:52 (31960) config: /home/ed/Documents/test/config/backgroundrb.yml 20061120-17:04:52 (31960) rails_env: development 20061120-17:04:52 (31960) Starting worker: BackgrounDRb::Worker::WorkerLogger backgroundrb_logger (backgroundrb_logger) () 20061120-17:04:52 (31960) Starting worker: BackgrounDRb::Worker::WorkerResults backgroundrb_results (backgroundrb_results) () 20061120-17:04:52 (31960) Loading Worker Class File: /home/ed/Documents/test/lib/workers/document_sorter_worker.rb 20061120-17:04:52 (31960) Loading Sechedule: argsclassdocument_sorter_worker trigger_typetriggerworker_methoddo_workworker_method_argsclassdocument_sorter_workertrigger_argsrepeat_interval1.minutestartMon Nov 20 17:04:57 CST 2006endMon Nov 20 17:04:52 CST 2006jobbleh # As far as I can tell backgroundrb loads my worker but I don't see any indication that its being ran every minute. At least not in development.log and backgroundrb_server.log Am I missing something ? Thanks in advance. -- Lalo From stockliasteroid at gmail.com Mon Nov 20 18:23:47 2006 From: stockliasteroid at gmail.com (Matt White) Date: Tue, 21 Nov 2006 12:23:47 +1300 Subject: [Backgroundrb-devel] Production RAILS_ENV / DB Selection Message-ID: <85f2e53f0611201523t5d0c254v36e4de83d41a02fa@mail.gmail.com> Hey all, I'm having some issues moving a project that incorporates Backgroundrb onto a staging server... For some reason (surely of my own doing), my RailsBase workers are insisting on using trying to access my development DB instead of my "production" DB. When I try to load a model object from within a worker, I get the following: 20061120-21:54:28 (26296) # 20061120-21:54:28 (26296) /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:387:in `real_connect' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:387:in `connect' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:151:in `initialize' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:82:in `mysql_connection' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:252:in `connection_without_query_cache=' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/query_cache.rb:54:in `connection=' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:220:in `retrieve_connection' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:78:in `connection' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:760:in `columns' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:768:in `columns_hash' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:1020:in `find_one' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:1011:in `find_from_ids' /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:416:in `find' /var/www/gorchie/releases/20061120100506/lib/workers/upload_process_worker.rb:14:in `do_work' /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:49:in `work_thread' /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:49:in `work_thread' /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' /usr/local/lib/ruby/gems/1.8/gems/slave-1.0.0/lib/slave.rb:205:in `initialize' /usr/local/lib/ruby/gems/1.8/gems/slave-1.0.0/lib/slave.rb:200:in `initialize' /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:169:in `new_worker' /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch' /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `dispatch' /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:159:in `new_worker' /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:215:in `run' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in `start_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/daemonize.rb:208:in `call_as_daemon' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:190:in `start_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:226:in `start' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/controller.rb:69:in `run' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in `run_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in `catch_exceptions' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:178:in `run_proc' /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:204:in `run' script/backgroundrb:29 I then went into the backgroundrb console and basically ran the same code as appears in the RailsBase.initialize() method to init the DB based on the current ENV['RAILS_ENV'] (which is set to "production" in my backgroundrb config file). The bit that calls establish_connection on ActiveRecord::Base works fine, and seems to connect to the production DB, because I'm able to run manual queries with execute() against it and get results. However, when I include environment.rb to load Rails, and then subsequently try to run queries against my models, I get the access denied error that indicates that it's trying to access my dev DB instead of my production DB. So, it seems that somehow Rails is starting in development mode even though I can confirm that ENV['RAILS_ENV'] == "production". However, if I check the value of RAILS_ENV while within the backgroundrb console, it is set to "development". So, for some reason ENV['RAILS_ENV'] does not have the same value as RAILS_ENV. So, I'm stumped. It all works fine locally, but I'm running in dev mode locally so this issue wouldn't surface. Any help or insight would be greatly appreciated. Thanks, Matt White -- Thermal Creative http://blog.thermalcreative.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061121/27544fd5/attachment.html From skaar at waste.org Mon Nov 20 17:42:22 2006 From: skaar at waste.org (skaar) Date: Mon, 20 Nov 2006 16:42:22 -0600 Subject: [Backgroundrb-devel] Passing object into results - "can't convert DRb::DRbUnknown into Hash - (TypeError)" In-Reply-To: <338f29120611201306j3059015cw9951197c48c1cfdf@mail.gmail.com> References: <338f29120611201306j3059015cw9951197c48c1cfdf@mail.gmail.com> Message-ID: <20061120224222.GB14523@waste.org> * David Lee (davidjy.lee at gmail.com) [061120 15:45]: > Hi, > > I'm using backgroundrb to get RSS feeds and pass them back to the > controller. I'm using the Ruby RSS library to parse the feed, which > returns an RSS object. After that I pass the object into the results hash, > but that's when this error occurs. Basically, this is what I have: > > rss = RSS::Parser.parse(response.body) > results[:feed] = rss # error! > > 20061120-15:46:19 (16250) > (drbunix:///tmp/backgroundrb.16249/backgroundrb_results_0) > /Users/guest/workspace/project_nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:101:in > `merge!' > 20061120-15:46:19 (16250) > (drbunix:///tmp/backgroundrb.16249/backgroundrb_results_0) > /Users/guest/workspace/project_nano/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:101:in > `set_result' > > Any ideas? it would seem like parse returns data that is not serializable over DRb from the perspective of the results worker. I need to think a little bit how to go about with this. I don't think we want the results worker to load all possible libraries that the workers are using. In this case, if we just add require 'rss' to the results worker it will work. Then if you run from the console, you would also have to add a require 'rss' to display the data properly. I've captured a simple case in: http://backgroundrb.devjavu.com/projects/backgroundrb/changeset/158 /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 skaar at waste.org Mon Nov 20 18:34:44 2006 From: skaar at waste.org (skaar) Date: Mon, 20 Nov 2006 17:34:44 -0600 Subject: [Backgroundrb-devel] schedule support on latest svn, a question In-Reply-To: References: Message-ID: <20061120233444.GC14523@waste.org> * Eduardo Dominguez (eduardodmz at gmail.com) [061120 17:31]: > I'm running the latest backgroundrb mainly for scheduled tasks support. > > As per the documentation I created the backgroundrb_schedules.yml with > the following: > > simple_label: > :class: :document_sorter_worker > :worker_method: :do_work > :job: :bleh > :trigger_args: > :start: <%= Time.now + 5.seconds %> > :end: <%= Time.now + 10.minutes > :repeat_interval: 1.minute I should probably remove the active_support reference in the docs, what if you try to just to: :repeat_interval: 60 (repeat interval is in seconds) /skaar From eduardodmz at gmail.com Mon Nov 20 22:58:20 2006 From: eduardodmz at gmail.com (Eduardo Dominguez) Date: Mon, 20 Nov 2006 21:58:20 -0600 Subject: [Backgroundrb-devel] schedule support on latest svn, a question In-Reply-To: <20061120233444.GC14523@waste.org> References: <20061120233444.GC14523@waste.org> Message-ID: Skaar, thanks a lot, that did it. :) On 11/20/06, skaar wrote: > * Eduardo Dominguez (eduardodmz at gmail.com) [061120 17:31]: > > I'm running the latest backgroundrb mainly for scheduled tasks support. > > > > As per the documentation I created the backgroundrb_schedules.yml with > > the following: > > > > simple_label: > > :class: :document_sorter_worker > > :worker_method: :do_work > > :job: :bleh > > :trigger_args: > > :start: <%= Time.now + 5.seconds %> > > :end: <%= Time.now + 10.minutes > > :repeat_interval: 1.minute > > I should probably remove the active_support reference in the docs, what > if you try to just to: > > :repeat_interval: 60 > > (repeat interval is in seconds) > /skaar > > -- Lalo From eduardodmz at gmail.com Mon Nov 20 23:57:44 2006 From: eduardodmz at gmail.com (Eduardo Dominguez) Date: Mon, 20 Nov 2006 22:57:44 -0600 Subject: [Backgroundrb-devel] rendering from within a worker Message-ID: I'm using backgroundrb for its scheduled jobs. Now, a job that runs on a daily basis creates an xml file that I currently create with an .rxml template. Can I run a controller action from within a worker ? Can I render() a template from within a worker ? Sorry, I haven't grasped the whole rails/backgroundrb relationship so I don't know what I can and not do. Thanks for any help. -- Lalo From gethemant at gmail.com Tue Nov 21 06:50:33 2006 From: gethemant at gmail.com (hemant) Date: Tue, 21 Nov 2006 17:20:33 +0530 Subject: [Backgroundrb-devel] small tip for killing workers Message-ID: People are still using cron jobs for killing one shot workers. I mean...workers, which they want to run only once. I guess putting a "exit 0" at the end of do_work is a better solution. I use it and works great. -- There was only one Road; that it was like a great river: its springs were at every doorstep, and every path was its tributary. From davidjy.lee at gmail.com Tue Nov 21 14:40:52 2006 From: davidjy.lee at gmail.com (David Lee) Date: Tue, 21 Nov 2006 14:40:52 -0500 Subject: [Backgroundrb-devel] Reusable workers Message-ID: <338f29120611211140t7ae4bd2axf20691b4b7ce7ae5@mail.gmail.com> Hello, I'm using the scheduler to create several reusable workers of the same type, .e.g., RSSWorker, so I can avoid the overhead of initializing new processes (as suggested by Ezra to my previous question). Creating new workers through the external yaml seems pretty straightforward, but my question is is there a way to call these workers without using the job key? Currently, to use these workers, I have to refer to them by their job key. If a particular worker is available, it will go to work; otherwise, the request gets queued up. But in my case, I'd like to be able to delegate work to ANY worker that's available, so the requests get serviced much more quickly. Just as an idea, I thought that it might be cool if Middleman.new_worker(:class => :rss_worker) would pick up an available worker from the pool and make it go to work :) To my knowledge, this kind of feature isn't available yet, but if anyone knows of a way this could be done, I'd appreciate any help. Thank you! David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061121/a7bb009e/attachment.html From stockliasteroid at gmail.com Tue Nov 21 15:28:00 2006 From: stockliasteroid at gmail.com (Matt White) Date: Wed, 22 Nov 2006 09:28:00 +1300 Subject: [Backgroundrb-devel] Production RAILS_ENV / DB Selection In-Reply-To: <85f2e53f0611201523t5d0c254v36e4de83d41a02fa@mail.gmail.com> References: <85f2e53f0611201523t5d0c254v36e4de83d41a02fa@mail.gmail.com> Message-ID: <85f2e53f0611211228o41031f1cr6e5bc6366646d63b@mail.gmail.com> More info... I've managed to duplicate the issue on my local machine, and it seems that since RailsBase is parsed before Config loads info (including my :rails_env), it boots Rails in it's default mode of "development". ( initializer.rb, line 5: RAILS_ENV = (ENV['RAILS_ENV'] || 'development').dup unless defined?(RAILS_ENV)) I could see it on the console by switching my production config with my dev config in my database.yml. So, if I try to access my "development" DB, it will throw errors, but "production" should work since it's actually my dev db. When I manually call new_worker on the console, I get authentication errors thrown that indicate that it's trying to access my development DB. The fix is to call reload! to force it to reload the worker classes. When the workers get reloaded, ENV['RAILS_ENV'] is picked up by boot.rb, and it starts targeting the right DB. So, if I call new_worker after calling reload! it all works fine. So...that said, anyone have any ideas about how to fix this? I obviously can't call reload on the MiddleMan every time I start a new worker to make sure that it's got the right RAILS_ENV... Thanks! Matt On 11/21/06, Matt White wrote: > > Hey all, > > I'm having some issues moving a project that incorporates Backgroundrb > onto a staging server... For some reason (surely of my own doing), my > RailsBase workers are insisting on using trying to access my development DB > instead of my "production" DB. > > When I try to load a model object from within a worker, I get the > following: > > 20061120-21:54:28 (26296) # > 20061120-21:54:28 (26296) > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:387:in > `real_connect' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:387:in > `connect' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:151:in > `initialize' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:82:in > `mysql_connection' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:252:in > `connection_without_query_cache=' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/query_cache.rb:54:in > `connection=' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:220:in > `retrieve_connection' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:78:in > `connection' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:760:in > `columns' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:768:in > `columns_hash' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:1020:in > `find_one' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:1011:in > `find_from_ids' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:416:in > `find' > /var/www/gorchie/releases/20061120100506/lib/workers/upload_process_worker.rb:14:in > `do_work' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:49:in > `work_thread' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:49:in > `work_thread' > /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' > /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' > /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' > /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' > /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' > /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' > /usr/local/lib/ruby/gems/1.8/gems/slave-1.0.0 /lib/slave.rb:205:in > `initialize' > /usr/local/lib/ruby/gems/1.8/gems/slave-1.0.0/lib/slave.rb:200:in > `initialize' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:169:in > `new_worker' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in > `dispatch' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > `dispatch' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:159:in > `new_worker' > /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' > /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' > /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' > /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' > /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' > /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:215:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in > `start_proc' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/daemonize.rb:208:in > `call_as_daemon' > /usr/local/lib/ruby/gems/1.8/gems/daemons- 1.0.3/lib/daemons/application.rb:190:in > `start_proc' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:226:in > `start' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/controller.rb:69:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in > `run_proc' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in > `catch_exceptions' > /usr/local/lib/ruby/gems/1.8/gems/daemons- 1.0.3/lib/daemons.rb:178:in > `run_proc' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:204:in > `run' > script/backgroundrb:29 > > I then went into the backgroundrb console and basically ran the same code > as appears in the RailsBase.initialize() method to init the DB based on > the current ENV['RAILS_ENV'] (which is set to "production" in my > backgroundrb config file). The bit that calls establish_connection on > ActiveRecord::Base works fine, and seems to connect to the production DB, > because I'm able to run manual queries with execute() against it and get > results. > > However, when I include environment.rb to load Rails, and then > subsequently try to run queries against my models, I get the access denied > error that indicates that it's trying to access my dev DB instead of my > production DB. So, it seems that somehow Rails is starting in development > mode even though I can confirm that ENV['RAILS_ENV'] == "production". > However, if I check the value of RAILS_ENV while within the backgroundrb > console, it is set to "development". So, for some reason ENV['RAILS_ENV'] > does not have the same value as RAILS_ENV. > > So, I'm stumped. It all works fine locally, but I'm running in dev mode > locally so this issue wouldn't surface. > > Any help or insight would be greatly appreciated. > > Thanks, > > Matt White > -- > Thermal Creative > http://blog.thermalcreative.com -- Thermal Creative http://blog.thermalcreative.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061122/530c6283/attachment.html From davidjy.lee at gmail.com Tue Nov 21 15:29:18 2006 From: davidjy.lee at gmail.com (David Lee) Date: Tue, 21 Nov 2006 15:29:18 -0500 Subject: [Backgroundrb-devel] rendering from within a worker In-Reply-To: References: Message-ID: <338f29120611211229m7e378685m4d797faaeb32b46d@mail.gmail.com> Why don't you put the file into results and then pick it up from a controller? Like in the backgroundrb example, you could poll a controller action to see if the worker has finished its job and if so, render the rxml from the controller. On 11/20/06, Eduardo Dominguez wrote: > > I'm using backgroundrb for its scheduled jobs. > > Now, a job that runs on a daily basis creates an xml file that I > currently create with an .rxml template. > > Can I run a controller action from within a worker ? Can I render() a > template from within a worker ? > > Sorry, I haven't grasped the whole rails/backgroundrb relationship so > I don't know what I can and not do. > > Thanks for any help. > -- > Lalo > _______________________________________________ > 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/20061121/56310ccc/attachment.html From skaar at waste.org Tue Nov 21 15:41:23 2006 From: skaar at waste.org (skaar) Date: Tue, 21 Nov 2006 14:41:23 -0600 Subject: [Backgroundrb-devel] Production RAILS_ENV / DB Selection In-Reply-To: <85f2e53f0611211228o41031f1cr6e5bc6366646d63b@mail.gmail.com> References: <85f2e53f0611201523t5d0c254v36e4de83d41a02fa@mail.gmail.com> <85f2e53f0611211228o41031f1cr6e5bc6366646d63b@mail.gmail.com> Message-ID: <20061121204123.GA17345@waste.org> I'll try to look at this. Could you give it a try and move: 5: require BACKGROUNDRB_ROOT + '/config/boot.rb' inside initialize in RailsBase - I'll see if we can do something about load order. thanks /skaar * Matt White (stockliasteroid at gmail.com) [061121 14:26]: > More info... > > I've managed to duplicate the issue on my local machine, and it seems that > since RailsBase is parsed before Config loads info (including my > :rails_env), it boots Rails in it's default mode of "development". ( > initializer.rb, line 5: RAILS_ENV = (ENV['RAILS_ENV'] || > 'development').dup unless defined?(RAILS_ENV)) > > I could see it on the console by switching my production config with my > dev config in my database.yml. So, if I try to access my "development" DB, > it will throw errors, but "production" should work since it's actually my > dev db. > > When I manually call new_worker on the console, I get authentication > errors thrown that indicate that it's trying to access my development DB. > The fix is to call reload! to force it to reload the worker classes. When > the workers get reloaded, ENV['RAILS_ENV'] is picked up by boot.rb, and it > starts targeting the right DB. So, if I call new_worker after calling > reload! it all works fine. > > So...that said, anyone have any ideas about how to fix this? I obviously > can't call reload on the MiddleMan every time I start a new worker to make > sure that it's got the right RAILS_ENV... > > Thanks! > > Matt > > On 11/21/06, Matt White <[1]stockliasteroid at gmail.com > wrote: > > Hey all, > > I'm having some issues moving a project that incorporates Backgroundrb > onto a staging server... For some reason (surely of my own doing), my > RailsBase workers are insisting on using trying to access my development > DB instead of my "production" DB. > > When I try to load a model object from within a worker, I get the > following: > > 20061120-21:54:28 (26296) # > 20061120-21:54:28 (26296) > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:387:in > `real_connect' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:387:in > `connect' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:151:in > `initialize' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:82:in > `mysql_connection' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:252:in > `connection_without_query_cache=' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/query_cache.rb:54:in > `connection=' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:220:in > `retrieve_connection' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:78:in > `connection' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:760:in > `columns' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:768:in > `columns_hash' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:1020:in > `find_one' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:1011:in > `find_from_ids' > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:416:in > `find' > /var/www/gorchie/releases/20061120100506/lib/workers/upload_process_worker.rb:14:in > `do_work' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:49:in > `work_thread' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:49:in > `work_thread' > /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' > /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' > /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' > /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' > /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' > /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' > /usr/local/lib/ruby/gems/1.8/gems/slave-1.0.0 /lib/slave.rb:205:in > `initialize' > /usr/local/lib/ruby/gems/1.8/gems/slave-1.0.0/lib/slave.rb:200:in > `initialize' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:169:in > `new_worker' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in > `dispatch' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > `dispatch' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:159:in > `new_worker' > /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' > /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' > /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' > /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' > /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' > /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:215:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in > `start_proc' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/daemonize.rb:208:in > `call_as_daemon' > /usr/local/lib/ruby/gems/1.8/gems/daemons- > 1.0.3/lib/daemons/application.rb:190:in `start_proc' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:226:in > `start' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/controller.rb:69:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in > `run_proc' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in > `catch_exceptions' > /usr/local/lib/ruby/gems/1.8/gems/daemons- 1.0.3/lib/daemons.rb:178:in > `run_proc' > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:204:in > `run' > script/backgroundrb:29 > > I then went into the backgroundrb console and basically ran the same > code as appears in the RailsBase.initialize() method to init the DB > based on the current ENV['RAILS_ENV'] (which is set to "production" in > my backgroundrb config file). The bit that calls establish_connection on > ActiveRecord::Base works fine, and seems to connect to the production > DB, because I'm able to run manual queries with execute() against it and > get results. > > However, when I include environment.rb to load Rails, and then > subsequently try to run queries against my models, I get the access > denied error that indicates that it's trying to access my dev DB instead > of my production DB. So, it seems that somehow Rails is starting in > development mode even though I can confirm that ENV['RAILS_ENV'] == > "production". However, if I check the value of RAILS_ENV while within > the backgroundrb console, it is set to "development". So, for some > reason ENV['RAILS_ENV'] does not have the same value as RAILS_ENV. > > So, I'm stumped. It all works fine locally, but I'm running in dev mode > locally so this issue wouldn't surface. > > Any help or insight would be greatly appreciated. > > Thanks, > > Matt White > -- > Thermal Creative > [2]http://blog.thermalcreative.com > > -- > Thermal Creative > [3]http://blog.thermalcreative.com > > References > > Visible links > 1. mailto:stockliasteroid at gmail.com > 2. http://blog.thermalcreative.com/ > 3. http://blog.thermalcreative.com/ > _______________________________________________ > 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 stockliasteroid at gmail.com Tue Nov 21 15:50:51 2006 From: stockliasteroid at gmail.com (Matt White) Date: Wed, 22 Nov 2006 09:50:51 +1300 Subject: [Backgroundrb-devel] Production RAILS_ENV / DB Selection In-Reply-To: <85f2e53f0611211228o41031f1cr6e5bc6366646d63b@mail.gmail.com> References: <85f2e53f0611201523t5d0c254v36e4de83d41a02fa@mail.gmail.com> <85f2e53f0611211228o41031f1cr6e5bc6366646d63b@mail.gmail.com> Message-ID: <85f2e53f0611211250u1e82378dgd6a4c051b3385eae@mail.gmail.com> And one more... Sorry for spamming the list, but I keep answering my own questions :) The problem seems to come from the fact that backgroundrb_server requires worker, which then in turn requires worker_rails, all before the config file is parsed, thus making it too early for Rails to load with the appropriate RAILS_ENV from the config file. So, I moved: unless BACKGROUNDRB_STANDALONE require 'backgroundrb/worker_rails' end from the end of worker.rb to near the end of BackgrounDRb::Server#config so that Worker::RailsBase is only loaded after the appropriate ENV['RAILS_ENV'] has been set. I've confirmed that this seems to fix the issue, and I'm able to hit the right DB now from the console without having to force a reload. So, Ezra or Skaar, do you have any comments? I've been kinda shooting in the dark, and I want to make sure I'm not way off base :) Thanks, Matt On 11/22/06, Matt White wrote: > > More info... > > I've managed to duplicate the issue on my local machine, and it seems that > since RailsBase is parsed before Config loads info (including my > :rails_env), it boots Rails in it's default mode of "development". ( > initializer.rb, line 5: RAILS_ENV = (ENV['RAILS_ENV'] || > 'development').dup unless defined?(RAILS_ENV)) > > I could see it on the console by switching my production config with my > dev config in my database.yml. So, if I try to access my "development" DB, > it will throw errors, but "production" should work since it's actually my > dev db. > > When I manually call new_worker on the console, I get authentication > errors thrown that indicate that it's trying to access my development DB. > The fix is to call reload! to force it to reload the worker classes. When > the workers get reloaded, ENV['RAILS_ENV'] is picked up by boot.rb, and it > starts targeting the right DB. So, if I call new_worker after calling > reload! it all works fine. > > So...that said, anyone have any ideas about how to fix this? I obviously > can't call reload on the MiddleMan every time I start a new worker to make > sure that it's got the right RAILS_ENV... > > Thanks! > > Matt > > On 11/21/06, Matt White wrote: > > > > Hey all, > > > > I'm having some issues moving a project that incorporates Backgroundrb > > onto a staging server... For some reason (surely of my own doing), my > > RailsBase workers are insisting on using trying to access my development DB > > instead of my "production" DB. > > > > When I try to load a model object from within a worker, I get the > > following: > > > > 20061120-21:54:28 (26296) # > > 20061120-21:54:28 (26296) > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:387:in > > `real_connect' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:387:in > > `connect' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:151:in > > `initialize' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:82:in > > `mysql_connection' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:252:in > > `connection_without_query_cache=' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/query_cache.rb:54:in > > `connection=' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:220:in > > `retrieve_connection' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:78:in > > `connection' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:760:in > > `columns' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:768:in > > `columns_hash' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:1020:in > > `find_one' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:1011:in > > `find_from_ids' > > /var/www/gorchie/releases/20061120100506/config/../vendor/rails/activerecord/lib/active_record/base.rb:416:in > > `find' > > /var/www/gorchie/releases/20061120100506/lib/workers/upload_process_worker.rb:14:in > > `do_work' > > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:49:in > > `work_thread' > > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/worker.rb:49:in > > `work_thread' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' > > /usr/local/lib/ruby/gems/1.8/gems/slave-1.0.0 /lib/slave.rb:205:in > > `initialize' > > /usr/local/lib/ruby/gems/1.8/gems/slave-1.0.0/lib/slave.rb:200:in > > `initialize' > > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:169:in > > `new_worker' > > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in > > `dispatch' > > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > > `dispatch' > > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:159:in > > `new_worker' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' > > /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' > > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:215:in > > `run' > > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in > > `start_proc' > > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/daemonize.rb:208:in > > `call_as_daemon' > > /usr/local/lib/ruby/gems/1.8/gems/daemons- 1.0.3/lib/daemons/application.rb:190:in > > `start_proc' > > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:226:in > > `start' > > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/controller.rb:69:in > > `run' > > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in > > `run_proc' > > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in > > `catch_exceptions' > > /usr/local/lib/ruby/gems/1.8/gems/daemons- 1.0.3/lib/daemons.rb:178:in > > `run_proc' > > /var/www/gorchie/releases/20061120100506/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:204:in > > `run' > > script/backgroundrb:29 > > > > I then went into the backgroundrb console and basically ran the same > > code as appears in the RailsBase.initialize() method to init the DB > > based on the current ENV['RAILS_ENV'] (which is set to "production" in my > > backgroundrb config file). The bit that calls establish_connection on > > ActiveRecord::Base works fine, and seems to connect to the production DB, > > because I'm able to run manual queries with execute() against it and get > > results. > > > > However, when I include environment.rb to load Rails, and then > > subsequently try to run queries against my models, I get the access denied > > error that indicates that it's trying to access my dev DB instead of my > > production DB. So, it seems that somehow Rails is starting in development > > mode even though I can confirm that ENV['RAILS_ENV'] == "production". > > However, if I check the value of RAILS_ENV while within the backgroundrb > > console, it is set to "development". So, for some reason ENV['RAILS_ENV'] > > does not have the same value as RAILS_ENV. > > > > So, I'm stumped. It all works fine locally, but I'm running in dev mode > > locally so this issue wouldn't surface. > > > > Any help or insight would be greatly appreciated. > > > > Thanks, > > > > Matt White > > -- > > Thermal Creative > > http://blog.thermalcreative.com > > > > > -- > Thermal Creative > http://blog.thermalcreative.com > -- Thermal Creative http://blog.thermalcreative.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061122/350049d3/attachment-0001.html From skaar at waste.org Tue Nov 21 16:50:19 2006 From: skaar at waste.org (skaar) Date: Tue, 21 Nov 2006 15:50:19 -0600 Subject: [Backgroundrb-devel] Production RAILS_ENV / DB Selection In-Reply-To: <85f2e53f0611211250u1e82378dgd6a4c051b3385eae@mail.gmail.com> References: <85f2e53f0611201523t5d0c254v36e4de83d41a02fa@mail.gmail.com> <85f2e53f0611211228o41031f1cr6e5bc6366646d63b@mail.gmail.com> <85f2e53f0611211250u1e82378dgd6a4c051b3385eae@mail.gmail.com> Message-ID: <20061121215019.GB17345@waste.org> * Matt White (stockliasteroid at gmail.com) [061121 15:08]: > And one more... Sorry for spamming the list, but I keep answering my own > questions :) > > The problem seems to come from the fact that backgroundrb_server requires > worker, which then in turn requires worker_rails, all before the config > file is parsed, thus making it too early for Rails to load with the > appropriate RAILS_ENV from the config file. So, I moved: > > unless BACKGROUNDRB_STANDALONE > require 'backgroundrb/worker_rails' > end ok, thanks for going through the trouble. In trunk r159 worker_rails is loaded in BackgrounDRb::Server#setup. I'd be great next time if you can log the issue, so we can keep track of things like this. thanks again /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 gladwig at gmx.de Wed Nov 22 06:47:54 2006 From: gladwig at gmx.de (=?ISO-8859-1?Q?G=FCnter_Ladwig?=) Date: Wed, 22 Nov 2006 12:47:54 +0100 Subject: [Backgroundrb-devel] Error when starting bgrdb Message-ID: <67B70467-7103-4E9F-9017-EEAAC1D0DA73@gmx.de> Hi, I get this error when starting bgdrb using "rake backgroundrb:start" (on a Mac using bgdrb 0.2.0): /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/backgroundrb/server/lib/ backgroundrb_server.rb:33:in `format_message': undefined method `strftime' for "2006-11-22T12:34:18.524572 ":String (NoMethodError) from /usr/lib/ruby/1.8/logger.rb:320:in `add' from /usr/lib/ruby/1.8/logger.rb:372:in `info' from /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/ backgroundrb/server/lib/backgroundrb_server.rb:133:in `config' from /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/ backgroundrb/server/lib/backgroundrb_server.rb:193:in `run' from /Users/gl/Projects/xxxxx/xxxxx/config/../script/ backgroundrb:29 Seems strftime is called on a String object instead of DateTime/Time. Any ideas? G?nter From gladwig at gmx.de Wed Nov 22 08:35:43 2006 From: gladwig at gmx.de (=?ISO-8859-1?Q?G=FCnter_Ladwig?=) Date: Wed, 22 Nov 2006 14:35:43 +0100 Subject: [Backgroundrb-devel] Error when starting bgrdb In-Reply-To: References: <67B70467-7103-4E9F-9017-EEAAC1D0DA73@gmx.de> Message-ID: <7548BC5F-0C84-41BB-B545-EB0A2BB82336@gmx.de> On 22.11.2006, at 13:08, hemant wrote: > On 11/22/06, G?nter Ladwig wrote: >> Hi, >> >> I get this error when starting bgdrb using "rake >> backgroundrb:start" (on a Mac using bgdrb 0.2.0): >> >> /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/backgroundrb/server/ >> lib/ >> backgroundrb_server.rb:33:in `format_message': undefined method >> `strftime' for "2006-11-22T12:34:18.524572 ":String (NoMethodError) >> from /usr/lib/ruby/1.8/logger.rb:320:in `add' >> from /usr/lib/ruby/1.8/logger.rb:372:in `info' >> from /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/ >> backgroundrb/server/lib/backgroundrb_server.rb:133:in `config' >> from /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/ >> backgroundrb/server/lib/backgroundrb_server.rb:193:in `run' >> from /Users/gl/Projects/xxxxx/xxxxx/config/../script/ >> backgroundrb:29 >> >> Seems strftime is called on a String object instead of DateTime/Time. >> Any ideas? >> >> G?nter >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel >> > > I thought rake backgroundrb:start was not stable/usable yet. Did you > try ./script/backgoundrb start ? Well, according to the readme it should work. Anyway, I tried starting the server using "./script/backgroundrb start", but that produces the same error. For that matter, even "./script/backgroundrb --help" does not work. I had a look at logger.rb from the Ruby installation, and it seems format_message, which is overriden in backgroundrb_server.rb, is called with a String as a timestamp. I'm just wondering why it's working for everybody else. G?nter From michael.dauria at gmail.com Wed Nov 22 08:53:11 2006 From: michael.dauria at gmail.com (Michael D'Auria) Date: Wed, 22 Nov 2006 08:53:11 -0500 Subject: [Backgroundrb-devel] Error when starting bgrdb In-Reply-To: <7548BC5F-0C84-41BB-B545-EB0A2BB82336@gmx.de> References: <67B70467-7103-4E9F-9017-EEAAC1D0DA73@gmx.de> <7548BC5F-0C84-41BB-B545-EB0A2BB82336@gmx.de> Message-ID: <1907e2ca0611220553i18f45562x4405849ed319e492@mail.gmail.com> Could you give us some version information? On 11/22/06, G?nter Ladwig wrote: > > > On 22.11.2006, at 13:08, hemant wrote: > > > On 11/22/06, G?nter Ladwig wrote: > >> Hi, > >> > >> I get this error when starting bgdrb using "rake > >> backgroundrb:start" (on a Mac using bgdrb 0.2.0): > >> > >> /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/backgroundrb/server/ > >> lib/ > >> backgroundrb_server.rb:33:in `format_message': undefined method > >> `strftime' for "2006-11-22T12:34:18.524572 ":String (NoMethodError) > >> from /usr/lib/ruby/1.8/logger.rb:320:in `add' > >> from /usr/lib/ruby/1.8/logger.rb:372:in `info' > >> from /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/ > >> backgroundrb/server/lib/backgroundrb_server.rb:133:in `config' > >> from /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/ > >> backgroundrb/server/lib/backgroundrb_server.rb:193:in `run' > >> from /Users/gl/Projects/xxxxx/xxxxx/config/../script/ > >> backgroundrb:29 > >> > >> Seems strftime is called on a String object instead of DateTime/Time. > >> Any ideas? > >> > >> G?nter > >> _______________________________________________ > >> Backgroundrb-devel mailing list > >> Backgroundrb-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > >> > > > > I thought rake backgroundrb:start was not stable/usable yet. Did you > > try ./script/backgoundrb start ? > > Well, according to the readme it should work. Anyway, I tried > starting the server using "./script/backgroundrb start", but that > produces the same error. For that matter, even "./script/backgroundrb > --help" does not work. > > I had a look at logger.rb from the Ruby installation, and it seems > format_message, which is overriden in backgroundrb_server.rb, is > called with a String as a timestamp. I'm just wondering why it's > working for everybody else. > > G?nter > > _______________________________________________ > 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/20061122/cb7c0142/attachment.html From gladwig at gmx.de Wed Nov 22 09:45:31 2006 From: gladwig at gmx.de (=?ISO-8859-1?Q?G=FCnter_Ladwig?=) Date: Wed, 22 Nov 2006 15:45:31 +0100 Subject: [Backgroundrb-devel] Error when starting bgrdb In-Reply-To: <1907e2ca0611220553i18f45562x4405849ed319e492@mail.gmail.com> References: <67B70467-7103-4E9F-9017-EEAAC1D0DA73@gmx.de> <7548BC5F-0C84-41BB-B545-EB0A2BB82336@gmx.de> <1907e2ca0611220553i18f45562x4405849ed319e492@mail.gmail.com> Message-ID: <0AA6FD29-62F2-4F6C-A85C-2AABC7866155@gmx.de> Hi, as I said I'm using bgdrb 0.2.0, which I just checked out yesterday. Ruby is the version that came with OS X: ruby 1.8.2 (2004-12-25) [powerpc-darwin8.0]. Rails is version 1.1.6. Alright, seems Ruby is the problem. I checked the latest source code and format_message is called with a Time object, instead of a String object as in 1.8.2. Seems they changed that. Never a good idea to override internal methods ;) Just installed Ruby 1.8.4 and now it works. Maybe add that to the readme? G?nter On 22.11.2006, at 14:53, Michael D'Auria wrote: > Could you give us some version information? > > On 11/22/06, G?nter Ladwig wrote: > On 22.11.2006, at 13:08, hemant wrote: > > > On 11/22/06, G?nter Ladwig wrote: > >> Hi, > >> > >> I get this error when starting bgdrb using "rake > >> backgroundrb:start" (on a Mac using bgdrb 0.2.0): > >> > >> /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/backgroundrb/server/ > >> lib/ > >> backgroundrb_server.rb:33:in `format_message': undefined method > >> `strftime' for "2006-11-22T12:34:18.524572 ":String (NoMethodError) > >> from /usr/lib/ruby/1.8/logger.rb:320:in `add' > >> from /usr/lib/ruby/1.8/logger.rb:372:in `info' > >> from /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/ > >> backgroundrb/server/lib/backgroundrb_server.rb:133:in `config' > >> from /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/ > >> backgroundrb/server/lib/backgroundrb_server.rb:193:in `run' > >> from /Users/gl/Projects/xxxxx/xxxxx/config/../script/ > >> backgroundrb:29 > >> > >> Seems strftime is called on a String object instead of DateTime/ > Time. > >> Any ideas? > >> > >> G?nter > >> _______________________________________________ > >> Backgroundrb-devel mailing list > >> Backgroundrb-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > >> > > > > I thought rake backgroundrb:start was not stable/usable yet. Did you > > try ./script/backgoundrb start ? > > Well, according to the readme it should work. Anyway, I tried > starting the server using "./script/backgroundrb start", but that > produces the same error. For that matter, even "./script/backgroundrb > --help" does not work. > > I had a look at logger.rb from the Ruby installation, and it seems > format_message, which is overriden in backgroundrb_server.rb, is > called with a String as a timestamp. I'm just wondering why it's > working for everybody else. > > G?nter > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > From stockliasteroid at gmail.com Wed Nov 22 17:25:24 2006 From: stockliasteroid at gmail.com (Matt White) Date: Thu, 23 Nov 2006 11:25:24 +1300 Subject: [Backgroundrb-devel] Zombies? Message-ID: <85f2e53f0611221425p20768436r3e524e87d827a63b@mail.gmail.com> Hey all, Quick question about handling completed workers... Most of my workers are one-offs that just let me spin off a long-running file transfer process and then they just need to self-destruct when completed. Thus, at the end of my do_work, I just call self.delete to (in theory) self-destruct. However, while checking the jobs.size from the console, I've noticed that this doesn't seem to be working. Further, by grabbing the worker keys via jobs.keys, I try to manually call delete_worker to kill them off, and I get a RuntimeError "not beating" from Slave. However, when I call jobs[key].shutdown? to see if the job is dead, it returns false, indicating the the job isn't "shut down". So, I can't seem to have the workers self-destruct, and I can't kill them from the MiddleMan, either. The only solution seems to be to call shutdown({:quiet => true}) to suppress errors from slave. However, I don't know if this will actually succeed in whacking the process... Calling gc! basically results in the same behavior, because it tries to call delete_worker and I get the same "not beating" error. If this is a bug, I'll put it in trac, but it seems like I must be doing something wrong. Thanks! -- Thermal Creative http://blog.thermalcreative.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061123/f613ecac/attachment.html From michael.dauria at gmail.com Wed Nov 22 18:52:32 2006 From: michael.dauria at gmail.com (Michael D'Auria) Date: Wed, 22 Nov 2006 18:52:32 -0500 Subject: [Backgroundrb-devel] Error when starting bgrdb In-Reply-To: <0AA6FD29-62F2-4F6C-A85C-2AABC7866155@gmx.de> References: <67B70467-7103-4E9F-9017-EEAAC1D0DA73@gmx.de> <7548BC5F-0C84-41BB-B545-EB0A2BB82336@gmx.de> <1907e2ca0611220553i18f45562x4405849ed319e492@mail.gmail.com> <0AA6FD29-62F2-4F6C-A85C-2AABC7866155@gmx.de> Message-ID: <1907e2ca0611221552p22df81fcuee8efa7f269d8cd5@mail.gmail.com> I thought that the Ruby version had to be 1.8.4 that's why i asked :) On 11/22/06, G?nter Ladwig wrote: > > Hi, > > as I said I'm using bgdrb 0.2.0, which I just checked out yesterday. > Ruby is the version that came with OS X: ruby 1.8.2 (2004-12-25) > [powerpc-darwin8.0]. Rails is version 1.1.6. > > Alright, seems Ruby is the problem. I checked the latest source code > and format_message is called with a Time object, instead of a String > object as in 1.8.2. Seems they changed that. Never a good idea to > override internal methods ;) > > Just installed Ruby 1.8.4 and now it works. Maybe add that to the > readme? > > G?nter > > > On 22.11.2006, at 14:53, Michael D'Auria wrote: > > > Could you give us some version information? > > > > On 11/22/06, G?nter Ladwig wrote: > > On 22.11.2006, at 13:08, hemant wrote: > > > > > On 11/22/06, G?nter Ladwig wrote: > > >> Hi, > > >> > > >> I get this error when starting bgdrb using "rake > > >> backgroundrb:start" (on a Mac using bgdrb 0.2.0): > > >> > > >> /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/backgroundrb/server/ > > >> lib/ > > >> backgroundrb_server.rb:33:in `format_message': undefined method > > >> `strftime' for "2006-11-22T12:34:18.524572 ":String (NoMethodError) > > >> from /usr/lib/ruby/1.8/logger.rb:320:in `add' > > >> from /usr/lib/ruby/1.8/logger.rb:372:in `info' > > >> from /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/ > > >> backgroundrb/server/lib/backgroundrb_server.rb:133:in `config' > > >> from /Users/gl/Projects/xxxxx/xxxxx/vendor/plugins/ > > >> backgroundrb/server/lib/backgroundrb_server.rb:193:in `run' > > >> from /Users/gl/Projects/xxxxx/xxxxx/config/../script/ > > >> backgroundrb:29 > > >> > > >> Seems strftime is called on a String object instead of DateTime/ > > Time. > > >> Any ideas? > > >> > > >> G?nter > > >> _______________________________________________ > > >> Backgroundrb-devel mailing list > > >> Backgroundrb-devel at rubyforge.org > > >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > >> > > > > > > I thought rake backgroundrb:start was not stable/usable yet. Did you > > > try ./script/backgoundrb start ? > > > > Well, according to the readme it should work. Anyway, I tried > > starting the server using "./script/backgroundrb start", but that > > produces the same error. For that matter, even "./script/backgroundrb > > --help" does not work. > > > > I had a look at logger.rb from the Ruby installation, and it seems > > format_message, which is overriden in backgroundrb_server.rb, is > > called with a String as a timestamp. I'm just wondering why it's > > working for everybody else. > > > > G?nter > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061122/57783eda/attachment.html From michael at mindtheshark.com Mon Nov 27 09:53:27 2006 From: michael at mindtheshark.com (Michael Hulet) Date: Mon, 27 Nov 2006 15:53:27 +0100 Subject: [Backgroundrb-devel] rails environment loaded but one plugin is undefined (using backgroundrb 0.2.0) Message-ID: <456AFBE7.8000308@mindtheshark.com> Hello all, I'm using BackgroundRb 0.2.0 (standalone) and in the do_work method of my worker, I'm working with objects from my Rails application. So in my config/backgroundrb.yml file, I added this line: :load_rails: true I think my worker isn't doing what I want him to do. So I opened the console and read these error lines: # ruby script/backgroundrb console irb: warn: can't alias jobs from irb_jobs. irb(#):001:0> Thumbnail => Thumbnail irb(#):002:0> Media NameError: undefined local variable or method `acts_as_taggable' for Media:Class from /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1129:in `method_missing' from /home/web/ecox.com/ftp/dev/config/../app/models/media.rb:2 from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:140:in `load' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:140:in `load' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:56:in `require_or_load' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:30:in `depend_on' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:85:in `require_dependency' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:98:in `const_missing' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:131:in `const_missing' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:133:in `send' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:133:in `const_missing' from (irb):2 irb(#):003:0> exit As you can see, I have "Thumbnail" and "Media" classes in my Rails application. They are recognized, so Rails application seems to be loaded. But my Media model uses the acts_as_taggable plugin... and so the above error shown. Do you know what I could do to load the plugin? Have a nice week, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: michael.vcf Type: text/x-vcard Size: 315 bytes Desc: not available Url : http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061127/60b87ab2/attachment.vcf From michael at mindtheshark.com Mon Nov 27 09:58:10 2006 From: michael at mindtheshark.com (Michael Hulet) Date: Mon, 27 Nov 2006 15:58:10 +0100 Subject: [Backgroundrb-devel] rails environment loaded but one plugin is undefined (using backgroundrb 0.2.0) In-Reply-To: <456AFBE7.8000308@mindtheshark.com> References: <456AFBE7.8000308@mindtheshark.com> Message-ID: <456AFD02.3060109@mindtheshark.com> Sorry, this little addition just to write I'm not using the standalone version of BackgroundRb but it's the plugin. Michael Hulet a ?crit : > Hello all, > > I'm using BackgroundRb 0.2.0 (standalone) and in the do_work method of > my worker, I'm working with objects from my Rails application. So in my > config/backgroundrb.yml file, I added this line: > > :load_rails: true > > I think my worker isn't doing what I want him to do. So I opened the > console and read these error lines: > > # ruby script/backgroundrb console > irb: warn: can't alias jobs from irb_jobs. > irb(#):001:0> Thumbnail > => Thumbnail > irb(#):002:0> Media > NameError: undefined local variable or method `acts_as_taggable' for > Media:Class > from > /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1129:in > `method_missing' > from /home/web/ecox.com/ftp/dev/config/../app/models/media.rb:2 > from > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:140:in > `load' > from > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:140:in > `load' > from > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:56:in > `require_or_load' > from > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:30:in > `depend_on' > from > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:85:in > `require_dependency' > from > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:98:in > `const_missing' > from > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:131:in > `const_missing' > from > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:133:in > `send' > from > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:133:in > `const_missing' > from (irb):2 > irb(#):003:0> exit > > As you can see, I have "Thumbnail" and "Media" classes in my Rails > application. They are recognized, so Rails application seems to be > loaded. But my Media model uses the acts_as_taggable plugin... and so > the above error shown. > > Do you know what I could do to load the plugin? > > Have a nice week, > > Michael > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: michael.vcf Type: text/x-vcard Size: 315 bytes Desc: not available Url : http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061127/23e08970/attachment.vcf From skaar at waste.org Mon Nov 27 16:03:59 2006 From: skaar at waste.org (skaar) Date: Mon, 27 Nov 2006 15:03:59 -0600 Subject: [Backgroundrb-devel] Zombies? In-Reply-To: <85f2e53f0611221425p20768436r3e524e87d827a63b@mail.gmail.com> References: <85f2e53f0611221425p20768436r3e524e87d827a63b@mail.gmail.com> Message-ID: <20061127210358.GD8044@waste.org> ok, this was was lingering for a while as I suspected it was related to another issue, but if you are running off trunk, the fix for this is in as of: http://backgroundrb.devjavu.com/projects/backgroundrb/changeset/160 we shouldn't be that far off from 0.2.1 now. /skaar * Matt White (stockliasteroid at gmail.com) [061122 16:47]: > Hey all, > > Quick question about handling completed workers... > > Most of my workers are one-offs that just let me spin off a long-running > file transfer process and then they just need to self-destruct when > completed. Thus, at the end of my do_work, I just call self.delete to (in > theory) self-destruct. > > However, while checking the jobs.size from the console, I've noticed that > this doesn't seem to be working. Further, by grabbing the worker keys via > jobs.keys, I try to manually call delete_worker to kill them off, and I > get a RuntimeError "not beating" from Slave. However, when I call > jobs[key].shutdown? to see if the job is dead, it returns false, > indicating the the job isn't "shut down". So, I can't seem to have the > workers self-destruct, and I can't kill them from the MiddleMan, either. > The only solution seems to be to call shutdown({:quiet => true}) to > suppress errors from slave. However, I don't know if this will actually > succeed in whacking the process... > > Calling gc! basically results in the same behavior, because it tries to > call delete_worker and I get the same "not beating" error. > > If this is a bug, I'll put it in trac, but it seems like I must be doing > something wrong. > > Thanks! > > -- > Thermal Creative > [1]http://blog.thermalcreative.com > > References > > Visible links > 1. http://blog.thermalcreative.com/ > _______________________________________________ > 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 ezmobius at gmail.com Tue Nov 28 19:56:36 2006 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Tue, 28 Nov 2006 16:56:36 -0800 Subject: [Backgroundrb-devel] BackgrounDRb 0.2.1 Release Message-ID: <5ACBD617-18AB-4E5B-B1D3-96610393C635@gmail.com> It's that time again friends. skaar has been at it again and has greatly improved the stability of the new system. And Ara Howard has helped a ton by working with us on the slave library to iron out the wrinkles./ The results is a lot nicer backgroundrb for everyone. I have to say another huge thanks to skaar. He has singlehandedly wrote almost all of this new version and many bug fixes. I am very glad to have the help as I have too many projects to work on currently. Thanks skaar! Get the latest tagged release here: http://svn.devjavu.com/backgroundrb/tags/release-0.2.1/ = BackgrounDRb Changelog This file contains a summary of changes in particular releases, for a detailed change history and tickets, go to: http://backgroundrb.devjavu.com/projects/backgroundrb/timeline == 0.2.1 (Released November 28, 2006 - r162) This release contains the accumulated fixes and enhancements after the dot oh! release. Beside updating BackgrounDRb, we strongly encourage you to update to Slave 1.1.0 which has important fixes that greatly improve how BackgrounDRb behaves. - Server: Improved logging of server events and exceptions. - Server: Change of default DRb protocol to drbunix (domain sockets) - Server: Re-add DRb ACL configuration (not needed for drbunix) - Server: new_worker race condition fix - Server: Jobs entries are now deleted properly when worker exits. - Scheduler: Several scheduler fixes. It was pretty much broken in 0.2.0 - Scheduler: New external schedule definition file - Scheduler: do_work semantic changes (README: Special case: :do_work) - Rails: disabled rake tasks for start/stop/restart for now. - Rails: disabled Rails unit test in worker generator - Documentation: Deprecation of TODO file, items are in trac now. - Documentation: CronTrigger documentation == 0.2.0 (Released October 30, 2006 - r105) Initial release of BackgrounDRb rewrite. This was is also the first versioned release. The README contains the best overview the the new architecture. This is the baseline release. -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From derek at caffeinedreams.ca Wed Nov 29 12:28:05 2006 From: derek at caffeinedreams.ca (Derek Doda) Date: Wed, 29 Nov 2006 12:28:05 -0500 Subject: [Backgroundrb-devel] Noob needs help installing backgroundrb on Windows XP Message-ID: <456DC325.80300@caffeinedreams.ca> Hey Guys, In the readme for Backgroundrb it says that windows support has been depcreated for this version, but then it goes on to mention how to use it in Windows. So I'm not sure if it should be running on windows or not, so I'll ask anyway. Also, I'm new to ruby and I'm also new to server administration, so I apologize if my questions are pretty simple. I've tried to install backgroundrb on windows by doing the following: Installed slave 1.0.0 by using 'gem install slave' which seemed to work Installed daemons 1.0.3. by using 'gem install daemons' which also seemed to work I downloaded backgroundrb via SVN into the vendor/plugin/backgroundrb vendor plugin. Did a 'rake backgroundrb:setup' When I try to view a page it only renders "

Application error

Rails application failed to start properly". These are the errors that I got from Apache 2.2 Premature end of script headers: dispatch.cgi C:/ruby/lib/ruby/1.8/pathname.rb:341:in `lstat': Invalid argument - /C:/work/websites/cms/build1/cms/public/C:/work/websites/cms/build1/cms/public/../config (Errno::EINVAL)\r \tfrom C:/ruby/lib/ruby/1.8/pathname.rb:341:in `realpath'\r \tfrom C:/work/websites/cms/build1/cms/public/../config/../vendor/plugins/backgroundrb/lib/middleman_rails_init.rb:2\r \tfrom C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'\r \tfrom C:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require'\r \tfrom C:/work/websites/cms/build1/cms/public/../config/../vendor/plugins/backgroundrb/init.rb:2:in `load_plugin'\r \tfrom C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:348:in `load_plugin'\r \tfrom C:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/core_ext/kernel/reporting.rb:11:in `silence_warnings'\r \tfrom C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:348:in `load_plugin'\r \tfrom C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:158:in `load_plugins'\r \tfrom C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:158:in `load_plugins'\r \tfrom C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:102:in `process'\r \tfrom C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:42:in `run'\r \tfrom C:/work/websites/cms/build1/cms/public/../config/environment.rb:13\r \tfrom C:/work/websites/cms/build1/cms/public/dispatch.cgi:3\r Any help would be appreciated Cheers, -Derek From ezmobius at gmail.com Wed Nov 29 15:04:33 2006 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Wed, 29 Nov 2006 12:04:33 -0800 Subject: [Backgroundrb-devel] Noob needs help installing backgroundrb on Windows XP In-Reply-To: <456DC325.80300@caffeinedreams.ca> References: <456DC325.80300@caffeinedreams.ca> Message-ID: <465C8FFA-8A6D-47F4-B5E2-0EA96E546388@brainspl.at> Hey Derek- Yeah the new version does not currently work on windows because slave does a lot of fork'ing which doesn't work seamlessly on windows. There is talk of working towards a windows version of slave that would allow backgroundrb 0.2.x to work on windows. But for now your options on windows is to use the new bdrb under cygwin, or use the older version of the plugin from the svn at rubyforge. That version still works fine and will work on windows. Cheers- -Ezra On Nov 29, 2006, at 9:28 AM, Derek Doda wrote: > Hey Guys, > > In the readme for Backgroundrb it says that windows support has been > depcreated for this version, but then it goes on to mention how to use > it in Windows. So I'm not sure if it should be running on windows or > not, so I'll ask anyway. Also, I'm new to ruby and I'm also new to > server administration, so I apologize if my questions are pretty > simple. > > I've tried to install backgroundrb on windows by doing the following: > > Installed slave 1.0.0 by using 'gem install slave' which seemed to > work > Installed daemons 1.0.3. by using 'gem install daemons' which also > seemed to work > > I downloaded backgroundrb via SVN into the vendor/plugin/backgroundrb > vendor plugin. > Did a 'rake backgroundrb:setup' > > When I try to view a page it only renders "

Application > error

Rails application failed to start properly". > > These are the errors that I got from Apache 2.2 > > Premature end of script headers: dispatch.cgi > C:/ruby/lib/ruby/1.8/pathname.rb:341:in `lstat': Invalid argument - > /C:/work/websites/cms/build1/cms/public/C:/work/websites/cms/build1/ > cms/public/../config > (Errno::EINVAL)\r > \tfrom C:/ruby/lib/ruby/1.8/pathname.rb:341:in `realpath'\r > \tfrom > C:/work/websites/cms/build1/cms/public/../config/../vendor/plugins/ > backgroundrb/lib/middleman_rails_init.rb:2\r > \tfrom C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: > 27:in > `require'\r > \tfrom > C:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/ > active_support/dependencies.rb:147:in > `require'\r > \tfrom > C:/work/websites/cms/build1/cms/public/../config/../vendor/plugins/ > backgroundrb/init.rb:2:in > `load_plugin'\r > \tfrom > C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:348:in > `load_plugin'\r > \tfrom > C:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/ > active_support/core_ext/kernel/reporting.rb:11:in > `silence_warnings'\r > \tfrom > C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:348:in > `load_plugin'\r > \tfrom > C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:158:in > `load_plugins'\r > \tfrom > C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:158:in > `load_plugins'\r > \tfrom > C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:102:in > `process'\r > \tfrom > C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:42:in > `run'\r > \tfrom C:/work/websites/cms/build1/cms/public/../config/ > environment.rb:13\r > \tfrom C:/work/websites/cms/build1/cms/public/dispatch.cgi:3\r > > Any help would be appreciated > > Cheers, > -Derek > > _______________________________________________ > 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 info at siebert-wd.de Wed Nov 29 15:49:29 2006 From: info at siebert-wd.de (Michael Siebert) Date: Wed, 29 Nov 2006 21:49:29 +0100 Subject: [Backgroundrb-devel] Noob needs help installing backgroundrb on Windows XP In-Reply-To: <465C8FFA-8A6D-47F4-B5E2-0EA96E546388@brainspl.at> References: <456DC325.80300@caffeinedreams.ca> <465C8FFA-8A6D-47F4-B5E2-0EA96E546388@brainspl.at> Message-ID: <4E5CDA5C-2961-475C-978E-67676F214DFE@siebert-wd.de> Hey y'all, if its only about fork'ing, there is a gem on rubyforge that does exactly that: provide fork on windows. http://rubyforge.org/projects/win32utils/ win32-process should do the trick. if you search the ml archives, you'll find a post by me about using backgroundrb in daemon mode on win32 (some time ago where bgdrb used fork for daemoning). unfortunately everyone ignored that post. hopefully you don't ignore that one again, since it worked wonderful when i tried it. dont know about slave, but i think win32-utils can help out a bit there. beware: i didnt test that trickt because a. im using sonme older thread-pool-version and b. hardly switch my windows pc on since i have my macbook :) solong... Micha Am 29.11.2006 um 21:04 schrieb Ezra Zygmuntowicz: > Hey Derek- > > Yeah the new version does not currently work on windows because > slave does a lot of fork'ing which doesn't work seamlessly on > windows. There is talk of working towards a windows version of slave > that would allow backgroundrb 0.2.x to work on windows. But for now > your options on windows is to use the new bdrb under cygwin, or use > the older version of the plugin from the svn at rubyforge. That > version still works fine and will work on windows. > > > Cheers- > > -Ezra > > On Nov 29, 2006, at 9:28 AM, Derek Doda wrote: > >> Hey Guys, >> >> In the readme for Backgroundrb it says that windows support has been >> depcreated for this version, but then it goes on to mention how to >> use >> it in Windows. So I'm not sure if it should be running on windows or >> not, so I'll ask anyway. Also, I'm new to ruby and I'm also new to >> server administration, so I apologize if my questions are pretty >> simple. >> >> I've tried to install backgroundrb on windows by doing the following: >> >> Installed slave 1.0.0 by using 'gem install slave' which seemed to >> work >> Installed daemons 1.0.3. by using 'gem install daemons' which also >> seemed to work >> >> I downloaded backgroundrb via SVN into the vendor/plugin/backgroundrb >> vendor plugin. >> Did a 'rake backgroundrb:setup' >> >> When I try to view a page it only renders "

Application >> error

Rails application failed to start properly". >> >> These are the errors that I got from Apache 2.2 >> >> Premature end of script headers: dispatch.cgi >> C:/ruby/lib/ruby/1.8/pathname.rb:341:in `lstat': Invalid argument - >> /C:/work/websites/cms/build1/cms/public/C:/work/websites/cms/build1/ >> cms/public/../config >> (Errno::EINVAL)\r >> \tfrom C:/ruby/lib/ruby/1.8/pathname.rb:341:in `realpath'\r >> \tfrom >> C:/work/websites/cms/build1/cms/public/../config/../vendor/plugins/ >> backgroundrb/lib/middleman_rails_init.rb:2\r >> \tfrom C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: >> 27:in >> `require'\r >> \tfrom >> C:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/ >> active_support/dependencies.rb:147:in >> `require'\r >> \tfrom >> C:/work/websites/cms/build1/cms/public/../config/../vendor/plugins/ >> backgroundrb/init.rb:2:in >> `load_plugin'\r >> \tfrom >> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:348:in >> `load_plugin'\r >> \tfrom >> C:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/ >> active_support/core_ext/kernel/reporting.rb:11:in >> `silence_warnings'\r >> \tfrom >> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:348:in >> `load_plugin'\r >> \tfrom >> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:158:in >> `load_plugins'\r >> \tfrom >> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:158:in >> `load_plugins'\r >> \tfrom >> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:102:in >> `process'\r >> \tfrom >> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:42:in >> `run'\r >> \tfrom C:/work/websites/cms/build1/cms/public/../config/ >> environment.rb:13\r >> \tfrom C:/work/websites/cms/build1/cms/public/dispatch.cgi:3\r >> >> Any help would be appreciated >> >> Cheers, >> -Derek >> >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel >> > > -- Ezra Zygmuntowicz > -- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel ----------------------------- Siebert Michael info at siebert-wd.de --- ACHTUNG potenzieller Amokl?ufer: spiele Killerspiele (Scarface, GTA, UT) schaue Horrorfilme (Wrong Turn, Texas Chainsaw Massacre) h?re Musik von Anarchisten und Dunklen (Rammstein, Tote Hosen, Wizo) h?re Nazi-Musik von den B?hsen Onkelz, bin also auch noch Neonazi war mal auf ner Antifa-Demo war beim B.U.N.D. ich mag Ironie From ezmobius at gmail.com Wed Nov 29 16:19:03 2006 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Wed, 29 Nov 2006 13:19:03 -0800 Subject: [Backgroundrb-devel] Noob needs help installing backgroundrb on Windows XP In-Reply-To: <4E5CDA5C-2961-475C-978E-67676F214DFE@siebert-wd.de> References: <456DC325.80300@caffeinedreams.ca> <465C8FFA-8A6D-47F4-B5E2-0EA96E546388@brainspl.at> <4E5CDA5C-2961-475C-978E-67676F214DFE@siebert-wd.de> Message-ID: <6FB7AEA5-D70F-4590-A823-B64A520CE671@gmail.com> Unfortunately that won't cut it in this case, I wish it would. Slave does more then just fork. It uses ipc and a few other things that just don't work yet on windows. There is a possibility it could be made to work but right now it does not, even with win32 process. -Ezra On Nov 29, 2006, at 12:49 PM, Michael Siebert wrote: > Hey y'all, > if its only about fork'ing, there is a gem on rubyforge that does > exactly that: provide fork on windows. > > http://rubyforge.org/projects/win32utils/ > > win32-process should do the trick. if you search the ml archives, > you'll find a post by me about using backgroundrb in daemon mode on > win32 (some time ago where bgdrb used fork for daemoning). > unfortunately everyone ignored that post. hopefully you don't > ignore that one again, since it worked wonderful when i tried it. > dont know about slave, but i think win32-utils can help out a bit > there. > beware: i didnt test that trickt because a. im using sonme older > thread-pool-version and b. hardly switch my windows pc on since i > have my macbook :) > > solong... > Micha > > Am 29.11.2006 um 21:04 schrieb Ezra Zygmuntowicz: > >> Hey Derek- >> >> Yeah the new version does not currently work on windows because >> slave does a lot of fork'ing which doesn't work seamlessly on >> windows. There is talk of working towards a windows version of slave >> that would allow backgroundrb 0.2.x to work on windows. But for now >> your options on windows is to use the new bdrb under cygwin, or use >> the older version of the plugin from the svn at rubyforge. That >> version still works fine and will work on windows. >> >> >> Cheers- >> >> -Ezra >> >> On Nov 29, 2006, at 9:28 AM, Derek Doda wrote: >> >>> Hey Guys, >>> >>> In the readme for Backgroundrb it says that windows support has been >>> depcreated for this version, but then it goes on to mention how >>> to use >>> it in Windows. So I'm not sure if it should be running on >>> windows or >>> not, so I'll ask anyway. Also, I'm new to ruby and I'm also new to >>> server administration, so I apologize if my questions are pretty >>> simple. >>> >>> I've tried to install backgroundrb on windows by doing the >>> following: >>> >>> Installed slave 1.0.0 by using 'gem install slave' which seemed to >>> work >>> Installed daemons 1.0.3. by using 'gem install daemons' which also >>> seemed to work >>> >>> I downloaded backgroundrb via SVN into the vendor/plugin/ >>> backgroundrb >>> vendor plugin. >>> Did a 'rake backgroundrb:setup' >>> >>> When I try to view a page it only renders "

Application >>> error

Rails application failed to start properly". >>> >>> These are the errors that I got from Apache 2.2 >>> >>> Premature end of script headers: dispatch.cgi >>> C:/ruby/lib/ruby/1.8/pathname.rb:341:in `lstat': Invalid argument - >>> /C:/work/websites/cms/build1/cms/public/C:/work/websites/cms/build1/ >>> cms/public/../config >>> (Errno::EINVAL)\r >>> \tfrom C:/ruby/lib/ruby/1.8/pathname.rb:341:in `realpath'\r >>> \tfrom >>> C:/work/websites/cms/build1/cms/public/../config/../vendor/plugins/ >>> backgroundrb/lib/middleman_rails_init.rb:2\r >>> \tfrom C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: >>> 27:in >>> `require'\r >>> \tfrom >>> C:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/ >>> active_support/dependencies.rb:147:in >>> `require'\r >>> \tfrom >>> C:/work/websites/cms/build1/cms/public/../config/../vendor/plugins/ >>> backgroundrb/init.rb:2:in >>> `load_plugin'\r >>> \tfrom >>> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:348:in >>> `load_plugin'\r >>> \tfrom >>> C:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/ >>> active_support/core_ext/kernel/reporting.rb:11:in >>> `silence_warnings'\r >>> \tfrom >>> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:348:in >>> `load_plugin'\r >>> \tfrom >>> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:158:in >>> `load_plugins'\r >>> \tfrom >>> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:158:in >>> `load_plugins'\r >>> \tfrom >>> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:102:in >>> `process'\r >>> \tfrom >>> C:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:42:in >>> `run'\r >>> \tfrom C:/work/websites/cms/build1/cms/public/../config/ >>> environment.rb:13\r >>> \tfrom C:/work/websites/cms/build1/cms/public/dispatch.cgi:3\r >>> >>> Any help would be appreciated >>> >>> Cheers, >>> -Derek >>> >>> _______________________________________________ >>> Backgroundrb-devel mailing list >>> Backgroundrb-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel >>> >> >> -- Ezra Zygmuntowicz-- Lead Rails Evangelist >> -- ez at engineyard.com >> -- Engine Yard, Serious Rails Hosting >> -- (866) 518-YARD (9273) >> >> >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > ----------------------------- > Siebert Michael > info at siebert-wd.de > > --- > > ACHTUNG potenzieller Amokl?ufer: > spiele Killerspiele (Scarface, GTA, UT) > schaue Horrorfilme (Wrong Turn, Texas Chainsaw Massacre) > h?re Musik von Anarchisten und Dunklen (Rammstein, Tote Hosen, Wizo) > h?re Nazi-Musik von den B?hsen Onkelz, bin also auch noch Neonazi > war mal auf ner Antifa-Demo > war beim B.U.N.D. > ich mag Ironie > > > > -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From chris at etechdata.com.au Thu Nov 30 21:52:27 2006 From: chris at etechdata.com.au (Chris H) Date: Fri, 01 Dec 2006 12:52:27 +1000 Subject: [Backgroundrb-devel] Worker won't start work Message-ID: <456F98EB.8000901@etechdata.com.au> (Sorry my last email had the wrong subject) Hi, I've just installed background rb 0.2.1. When I try start a worker in my application controller I receive the following error: wrong number of arguments (2 for 1) - (ArgumentError) /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in `initialize' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in `new_worker' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `dispatch' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in `new_worker' /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:315:in `run' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in `start_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:196:in `start_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:226:in `start' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/controller.rb:72:in `run' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in `run_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in `catch_exceptions' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:178:in `run_proc' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in `run' I'm running slave (1.1.0) and daemons (1.0.3) as required. I'm starting the worker with: MiddleMan.new_worker(:class => :calls_worker, :job_key => :calls_watcher) thanks in advance! cheers, chris. From chris at etechdata.com.au Thu Nov 30 21:51:34 2006 From: chris at etechdata.com.au (Chris H) Date: Fri, 01 Dec 2006 12:51:34 +1000 Subject: [Backgroundrb-devel] Noob needs help installing backgroundrb on Windows XP In-Reply-To: <6FB7AEA5-D70F-4590-A823-B64A520CE671@gmail.com> References: <456DC325.80300@caffeinedreams.ca> <465C8FFA-8A6D-47F4-B5E2-0EA96E546388@brainspl.at> <4E5CDA5C-2961-475C-978E-67676F214DFE@siebert-wd.de> <6FB7AEA5-D70F-4590-A823-B64A520CE671@gmail.com> Message-ID: <456F98B6.4080700@etechdata.com.au> Hi, I've just installed background rb 0.2.1. When I try start a worker in my application controller I receive the following error: wrong number of arguments (2 for 1) - (ArgumentError) /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in `initialize' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in `new_worker' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in `dispatch' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in `dispatch' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in `new_worker' /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:315:in `run' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in `start_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:196:in `start_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:226:in `start' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/controller.rb:72:in `run' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in `run_proc' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in `catch_exceptions' /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:178:in `run_proc' /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in `run' I'm running slave (1.1.0) and daemons (1.0.3) as required. I'm starting the worker with: MiddleMan.new_worker(:class => :calls_worker, :job_key => :calls_watcher) thanks in advance! cheers, chris. From skaar at waste.org Thu Nov 30 22:40:42 2006 From: skaar at waste.org (skaar) Date: Thu, 30 Nov 2006 21:40:42 -0600 Subject: [Backgroundrb-devel] Noob needs help installing backgroundrb on Windows XP In-Reply-To: <456F98B6.4080700@etechdata.com.au> References: <456DC325.80300@caffeinedreams.ca> <465C8FFA-8A6D-47F4-B5E2-0EA96E546388@brainspl.at> <4E5CDA5C-2961-475C-978E-67676F214DFE@siebert-wd.de> <6FB7AEA5-D70F-4590-A823-B64A520CE671@gmail.com> <456F98B6.4080700@etechdata.com.au> Message-ID: <20061201034042.GA14440@waste.org> hmm, do you have your own initialize in your worker class? can you give us a skeleton of your worker class? /skaar * Chris H (chris at etechdata.com.au) [061130 21:38]: > Hi, > > I've just installed background rb 0.2.1. > > When I try start a worker in my application controller I receive the > following error: > > > wrong number of arguments (2 for 1) - (ArgumentError) > /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in > `initialize' > /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in > `new_worker' > /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in > `dispatch' > /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in > `dispatch' > /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in > `new_worker' > /usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' > /usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' > /usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' > /usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' > /usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' > /usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' > /usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' > /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:315:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in > `start_proc' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:196:in > `start_proc' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:226:in > `start' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/controller.rb:72:in > `run' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in > `run_proc' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in > `catch_exceptions' > /usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:178:in > `run_proc' > /home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in > `run' > > > I'm running slave (1.1.0) and daemons (1.0.3) as required. > > I'm starting the worker with: > MiddleMan.new_worker(:class => :calls_worker, :job_key => :calls_watcher) > > thanks in advance! > > cheers, > chris. > > > _______________________________________________ > 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 chris at etechdata.com.au Thu Nov 30 23:07:15 2006 From: chris at etechdata.com.au (Chris H) Date: Fri, 01 Dec 2006 14:07:15 +1000 Subject: [Backgroundrb-devel] Noob needs help installing backgroundrb on Windows XP In-Reply-To: <20061201034042.GA14440@waste.org> References: <456DC325.80300@caffeinedreams.ca> <465C8FFA-8A6D-47F4-B5E2-0EA96E546388@brainspl.at> <4E5CDA5C-2961-475C-978E-67676F214DFE@siebert-wd.de> <6FB7AEA5-D70F-4590-A823-B64A520CE671@gmail.com> <456F98B6.4080700@etechdata.com.au> <20061201034042.GA14440@waste.org> Message-ID: <456FAA73.4020001@etechdata.com.au> I removed my initialize method and it's working as expected :) this is what I had: def initialize(args) @running = true super(args) end def do_work(args) # This method is called in it's own new thread when you # call new worker. args is set to :args while @running #code went here end end now I'ved moved @running = true into do_work. How come I wasn't able to do what I did with initialize? Cheers, chris. >hmm, do you have your own initialize in your worker class? can you give >us a skeleton of your worker class? > >/skaar > > >* Chris H (chris at etechdata.com.au) [061130 21:38]: > > >>Hi, >> >>I've just installed background rb 0.2.1. >> >>When I try start a worker in my application controller I receive the >>following error: >> >> >>wrong number of arguments (2 for 1) - (ArgumentError) >>/home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in >>`initialize' >>/home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:211:in >>`new_worker' >>/home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in >>`dispatch' >>/home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in >>`dispatch' >>/home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in >>`new_worker' >>/usr/local/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block' >>/usr/local/lib/ruby/1.8/drb/drb.rb:1512:in `perform' >>/usr/local/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop' >>/usr/local/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop' >>/usr/local/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop' >>/usr/local/lib/ruby/1.8/drb/drb.rb:1427:in `run' >>/usr/local/lib/ruby/1.8/drb/drb.rb:1424:in `run' >>/usr/local/lib/ruby/1.8/drb/drb.rb:1344:in `initialize' >>/usr/local/lib/ruby/1.8/drb/drb.rb:1624:in `start_service' >>/home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:315:in >>`run' >>/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:186:in >>`start_proc' >>/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:196:in >>`start_proc' >>/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/application.rb:226:in >>`start' >>/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/controller.rb:72:in >>`run' >>/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:179:in >>`run_proc' >>/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons/cmdline.rb:94:in >>`catch_exceptions' >>/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.3/lib/daemons.rb:178:in >>`run_proc' >>/home/chris/projects/call_manager/trunk/call_manager_app/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in >>`run' >> >> >>I'm running slave (1.1.0) and daemons (1.0.3) as required. >> >>I'm starting the worker with: >>MiddleMan.new_worker(:class => :calls_worker, :job_key => :calls_watcher) >> >>thanks in advance! >> >>cheers, >>chris. >> >> >>_______________________________________________ >>Backgroundrb-devel mailing list >>Backgroundrb-devel at rubyforge.org >>http://rubyforge.org/mailman/listinfo/backgroundrb-devel >> >> > > >