Hi, First, thanks for the plugin. Sorry if this is not strictly a backgroundrb issue but I thought others on this list might have come across this problem. I''m trying to run the test that comes via the worker generator. The test works fine when running ''rake test_functional'', but when the tests are run by autotest I get "uninitialized constant BackgrounDRb" (full stack trace below). I notice that BackgrounDRb::Rails is defined in "script/lib", is this a non-standard location that autotest somehow bypasses? I''m totally clueless as to how Rails loads plugins, so if anyone else has seen this issue, help appreciated. The stack trace: /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:123:in `const_missing'': uninitialized constant BackgrounDRb (NameError) from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:131:in `const_missing'' from /home/jhughes/work/project-tracker-rails/trunk/config/../lib/workers/task_checker_worker.rb:5 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require'' from ./test/unit/task_checker_worker_test.rb:2 from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:140:in `load'' from -e:1 from -e:1 /usr/lib/ruby/gems/1.8/gems/ZenTest-3.2.0/lib/unit_diff.rb:196:in `unit_diff'': undefined method `first'' for nil:NilClass (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.2.0/lib/unit_diff.rb:84:in `unit_diff'' from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.2.0/bin/unit_diff:38 from /usr/bin/unit_diff:18 -- James Hughes Web application developer Vancouver, BC "Developing a coherent political analysis is in many respects contingent upon an ability to connect one context to another, a process not dissimilar to playing the kid''s game of dot-to-dot." - Ward Churchill, from ''"A Government of Laws"?''
On Jul 18, 2006, at 11:51 AM, James Hughes wrote:> Hi, > > First, thanks for the plugin. Sorry if this is not strictly a > backgroundrb issue but I thought others on this list might have come > across this problem. > > I''m trying to run the test that comes via the worker generator. The > test works fine when running ''rake test_functional'', but when the > tests are run by autotest I get "uninitialized constant BackgrounDRb" > (full stack trace below). I notice that BackgrounDRb::Rails is defined > in "script/lib", is this a non-standard location that autotest somehow > bypasses? I''m totally clueless as to how Rails loads plugins, so if > anyone else has seen this issue, help appreciated. >'' Hey James- Yeah having the main file in script/lib was a mistake. I have changed that in more recent version s to leave all code exzcept for stubs for the start and stop scripts within the plugin. So I recommend that you update to the newest version of the plugin and start from there. I''m not sure how autotest will deal with testing workers. It is a bit tough to test the workers in there real life state and I haven''t used autotest with this plugin yet. So try it with the latest version and let me know if that works for you. You will need to remove the entire script/backgroundrb folder and the config/backgroundrb.yml files from your app and run rake backgroundrb:setup again once you install the new version. -Ezra> The stack trace: > > /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/ > dependencies.rb:123:in > `const_missing'': uninitialized constant BackgrounDRb (NameError) > from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/ > active_support/dependencies.rb:131:in > `const_missing'' > from /home/jhughes/work/project-tracker-rails/trunk/config/../lib/ > workers/task_checker_worker.rb:5 > from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require'' > from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/ > active_support/dependencies.rb:147:in > `require'' > from ./test/unit/task_checker_worker_test.rb:2 > from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/ > active_support/dependencies.rb:140:in > `load'' > from -e:1 > from -e:1 > /usr/lib/ruby/gems/1.8/gems/ZenTest-3.2.0/lib/unit_diff.rb:196:in > `unit_diff'': undefined method `first'' for nil:NilClass (NoMethodError) > from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.2.0/lib/unit_diff.rb:84:in > `unit_diff'' > from /usr/lib/ruby/gems/1.8/gems/ZenTest-3.2.0/bin/unit_diff:38 > from /usr/bin/unit_diff:18 > > -- > James Hughes > Web application developer > Vancouver, BC > > "Developing a coherent political analysis is in many respects > contingent upon an ability to connect one context to another, a > process not dissimilar to playing the kid''s game of dot-to-dot." > - Ward Churchill, from ''"A Government of Laws"?'' > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
(Ezra, sorry for the repeat, I didn''t hit reply-all the first time so this didn''t get to the list) On 7/18/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:> > On Jul 18, 2006, at 11:51 AM, James Hughes wrote: > > > Hi, > > I''m trying to run the test that comes via the worker generator. The > > test works fine when running ''rake test_functional'', but when theScratch that test_functional above. The generated test is a *unit* test, so no wonder the functional tests were running without error. ;] Anyway, the upshot is that this is not an autotest issue, but a testing issue in general. [goes away and hacks a bit] Ok, found the problem; in the generated test, these two lines need to be reversed so that the backgroundrb lib is loaded before the worker class: require "#{RAILS_ROOT}/lib/workers/task_checker_worker" require "#{RAILS_ROOT}/vendor/plugin/backgroundrb/backgroundrb.rb" Also, it should be /vendor/plugins/, not /vendor/plugin. So, lines 2 and 3 of your test end up like the following: require "#{RAILS_ROOT}/vendor/plugins/backgroundrb/backgroundrb.rb" require "#{RAILS_ROOT}/lib/workers/task_checker_worker" jh -- James Hughes Web application developer Vancouver, BC "Developing a coherent political analysis is in many respects contingent upon an ability to connect one context to another, a process not dissimilar to playing the kid''s game of dot-to-dot." - Ward Churchill, from ''"A Government of Laws"?''
Hi~ On Jul 19, 2006, at 10:41 AM, James Hughes wrote:> (Ezra, sorry for the repeat, I didn''t hit reply-all the first time so > this didn''t get to the list) > On 7/18/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote: >> >> On Jul 18, 2006, at 11:51 AM, James Hughes wrote: >> >>> Hi, >>> I''m trying to run the test that comes via the worker generator. The >>> test works fine when running ''rake test_functional'', but when the > > Scratch that test_functional above. The generated test is a *unit* > test, so no wonder the functional tests were running without error. ;] > > Anyway, the upshot is that this is not an autotest issue, but a > testing issue in general. > > [goes away and hacks a bit] > > Ok, found the problem; in the generated test, these two lines need to > be reversed so that the backgroundrb lib is loaded before the worker > class: > > require "#{RAILS_ROOT}/lib/workers/task_checker_worker" > require "#{RAILS_ROOT}/vendor/plugin/backgroundrb/backgroundrb.rb" > > Also, it should be /vendor/plugins/, not /vendor/plugin. > > So, lines 2 and 3 of your test end up like the following: > > require "#{RAILS_ROOT}/vendor/plugins/backgroundrb/backgroundrb.rb" > require "#{RAILS_ROOT}/lib/workers/task_checker_worker" > > > jh > > -- > James HughesHey James- Thanks for that. I just commited this change to the generated test case. So it should be fixed now. Good catch. Thanks -Ezra
Hi Ezra,
love backgroundrb! Awesome plugin!
I have a worker that processes some data files and loads this data in mysql.
It runs fine and processes all the files.
However if I try to call delete_worker from my controller while it is
processing ,
it says it has stopped the worker but I can still see the process
in top and also see the rows still going into mysql.
My do_work looks like this:
def do_work(args)
# This method is called in it''s own new thread when you
# call new worker. args is set to :args
if args
@process_cdr = ProcessCdr.new(args)
else
@process_cdr = ProcessCdr.new
end
@process_cdr.process
end
I have start and stop actions in my controller:
def start
if @params[:cdr_file].to_s.length > 0
MiddleMan[:process_watcher] ||MiddleMan.new_worker(:class =>
:watch_cdr_process_worker, :args => @params[:cdr_file].to_s, :job_key =>
:process_watcher)
else
MiddleMan[:process_watcher] || MiddleMan.new_worker(:class =>
:watch_cdr_process_worker, :job_key => :process_watcher)
end
redirect_to :action => ''status''
end
def stop
MiddleMan.delete_worker(:process_watcher) if MiddleMan[:process_watcher]
redirect_to :action => ''status''
end
I have some ajax code monitoring the status of my worker and when I
choose stop it responds that my worker has indeed stopped.
I also tried adding a method stop_work to my worker which called
self.terminate but this didn''t seem to work either.
I''m confused as to what I should be doing to get my worker to stop.
Thanks in advance,
Chris.
Ezra Zygmuntowicz
2006-Jul-25 15:59 UTC
[Backgroundrb-devel] MY worker won''t stop working
Hi~ On Jul 24, 2006, at 11:25 PM, Chris H wrote:> Hi Ezra, > > love backgroundrb! Awesome plugin!Thanks!> > I have a worker that processes some data files and loads this data > in mysql. > It runs fine and processes all the files. > > However if I try to call delete_worker from my controller while it is > processing , > it says it has stopped the worker but I can still see the process > in top and also see the rows still going into mysql. > > > My do_work looks like this: > > def do_work(args) > # This method is called in it''s own new thread when you > # call new worker. args is set to :args > if args > @process_cdr = ProcessCdr.new(args) > else > @process_cdr = ProcessCdr.new > end > @process_cdr.process > > end > > I have start and stop actions in my controller: > > def start > > if @params[:cdr_file].to_s.length > 0 > > MiddleMan[:process_watcher] ||MiddleMan.new_worker(:class => > :watch_cdr_process_worker, :args => @params > [:cdr_file].to_s, :job_key => > :process_watcher) > > else > > MiddleMan[:process_watcher] || MiddleMan.new_worker(:class => > :watch_cdr_process_worker, :job_key => :process_watcher) > > end > > redirect_to :action => ''status'' > > end > > def stop > > MiddleMan.delete_worker(:process_watcher) if MiddleMan > [:process_watcher]Middleman[:process_watcher].terminate && MiddleMan.delete_worker (:process_watcher)> redirect_to :action => ''status'' > > end > > I have some ajax code monitoring the status of my worker and when I > choose stop it responds that my worker has indeed stopped. > > I also tried adding a method stop_work to my worker which called > self.terminate but this didn''t seem to work either. > > I''m confused as to what I should be doing to get my worker to stop. > > Thanks in advance, > Chris.Chris- When you say you can see the process in top still what do you mean? Killing one worker will not stop the whole backgroundrb process so it will still show in top. The way terminate works is that you call it and it will signal the thread handle that it is ok to delete this worker. THen delete_worker will actually delete it. The next release will have a method you can use in your worker to kill it from within itself when its finished. See if using terminate this way works for you and let me know. Thanks -Ezra
Hi Ezra, thanks for the reply. There''s a ruby process that appears in top when I fire off the do_work method. It uses around 30-50% cpu and disappears once all processing has completed. When I try to stop processing using delete_worker I was expecting this ruby process to stop, but understand/expect that backgroundrb is still running. I tried MiddleMan[:process_watcher].terminate && MiddleMan.delete_worker (:process_watcher) however this seems to do less then MiddleMan.delete_worker (:process_watcher) on its own. As Michael Siebert wrote, will I need to have do_work return when I want my process to stop? Thanks in advance, Chris.> Hi~ > > On Jul 24, 2006, at 11:25 PM, Chris H wrote: > >> Hi Ezra, >> >> love backgroundrb! Awesome plugin! > > > Thanks! > >> >> I have a worker that processes some data files and loads this data >> in mysql. >> It runs fine and processes all the files. >> >> However if I try to call delete_worker from my controller while it is >> processing , >> it says it has stopped the worker but I can still see the process >> in top and also see the rows still going into mysql. >> >> >> My do_work looks like this: >> >> def do_work(args) >> # This method is called in it''s own new thread when you >> # call new worker. args is set to :args >> if args >> @process_cdr = ProcessCdr.new(args) >> else >> @process_cdr = ProcessCdr.new >> end >> @process_cdr.process >> >> end >> >> I have start and stop actions in my controller: >> >> def start >> >> if @params[:cdr_file].to_s.length > 0 >> >> MiddleMan[:process_watcher] ||MiddleMan.new_worker(:class => >> :watch_cdr_process_worker, :args => @params [:cdr_file].to_s, >> :job_key => >> :process_watcher) >> >> else >> >> MiddleMan[:process_watcher] || MiddleMan.new_worker(:class => >> :watch_cdr_process_worker, :job_key => :process_watcher) >> >> end >> >> redirect_to :action => ''status'' >> >> end >> >> def stop >> >> MiddleMan.delete_worker(:process_watcher) if MiddleMan >> [:process_watcher] > > > Middleman[:process_watcher].terminate && MiddleMan.delete_worker > (:process_watcher) > > >> redirect_to :action => ''status'' >> >> end >> >> I have some ajax code monitoring the status of my worker and when I >> choose stop it responds that my worker has indeed stopped. >> >> I also tried adding a method stop_work to my worker which called >> self.terminate but this didn''t seem to work either. >> >> I''m confused as to what I should be doing to get my worker to stop. >> >> Thanks in advance, >> Chris. > > > Chris- > > When you say you can see the process in top still what do you > mean? Killing one worker will not stop the whole backgroundrb process > so it will still show in top. The way terminate works is that you > call it and it will signal the thread handle that it is ok to delete > this worker. THen delete_worker will actually delete it. The next > release will have a method you can use in your worker to kill it from > within itself when its finished. > > See if using terminate this way works for you and let me know. > > Thanks > -Ezra > > > > >
Ezra Zygmuntowicz
2006-Jul-31 14:44 UTC
[Backgroundrb-devel] MY worker won''t stop working
On Jul 30, 2006, at 5:11 PM, Chris H wrote:> Hi Ezra, > > thanks for the reply. > > There''s a ruby process that appears in top when I fire off the do_work > method. > It uses around 30-50% cpu and disappears once all processing has > completed. > > When I try to stop processing using delete_worker I was expecting this > ruby process to stop, > but understand/expect that backgroundrb is still running. > > I tried > MiddleMan[:process_watcher].terminate && MiddleMan.delete_worker > (:process_watcher) > however this seems to do less then MiddleMan.delete_worker > (:process_watcher) on its own. > > As Michael Siebert wrote, will I need to have do_work return when I > want > my process to stop? > > Thanks in advance, > Chris.Hey Chris- By itself Backgroundrb won''t spawn any extra processes except for itself. Are you doing a system call or using `` to call an external program? Or are you using fork at all? Maybe if you paste your worker code and how you are calling it here I can help you track down the issue. -Ezra