Chris T
2006-Oct-12 15:18 UTC
[Backgroundrb-devel] BackgrounDRb newbie stuck at first base. Fresh pair of eyes needed
Can''t believe I can''t see the problem here, but after a few hours bashing my head on a brick wall, going to risk looking stupid by seeing if anyone can point out my idiocy (that''s the worst thing about coding on your own). Trying to get BackgrounDRb to take over the scraping task which is currently being done in a Rails controller. That''s not the problem at the moment, as I can''t even get past first base. For some reason, it doesn''t seem to be setting up my worker class properly. Here''s my worker class def: |class ScrapeWorker < BackgrounDRb::Rails attr_accessor :progress, :message, :ids_retrieved def do_work(args) @progress = 0 @message = args[:message] || "" @job_completed = false @hse_notices_retrieved = 0 puts args[:message] get_new_ids(args) end def get_new_ids(args) .... end end| However, I get NoMethodError (undefined method `ids_retrieved'' for #<ScrapeWorker:0x2a678b8>) Set up a quick unit test, and not surprisingly fails on first respond_to | def test_should_respond_to_progress_message_and_hse_notices_retrieved MiddleMan.new_worker(:class => :scrape_worker, :args => {:message => "Uh -Oh"}, :job_key => :test_scraper, :ttl => 5) s = MiddleMan[:test_scraper] assert s.respond_to?(:progress) assert s.respond_to?(:message) assert s.respond_to?(:hse_notices_retrieved) assert_equal "Uh -Oh", s.message end| I''m sure it must be something really obviously but can''t for the life of me work out what. Any ideas? Thanks in advance Chris p.s. I''m on OS X, though not sure that''s relevant here...
Charles Brian Quinn
2006-Oct-12 15:49 UTC
[Backgroundrb-devel] BackgrounDRb newbie stuck at first base. Fresh pair of eyes needed
should it be: s = MiddleMan.get_worker(:test_scraper) ? On 10/12/06, Chris T <ctmailinglists at googlemail.com> wrote:> Can''t believe I can''t see the problem here, but after a few hours > bashing my head on a brick wall, going to risk looking stupid by seeing > if anyone can point out my idiocy (that''s the worst thing about coding > on your own). > > Trying to get BackgrounDRb to take over the scraping task which is > currently being done in a Rails controller. That''s not the problem at > the moment, as I can''t even get past first base. For some reason, it > doesn''t seem to be setting up my worker class properly. > > Here''s my worker class def: > > |class ScrapeWorker < BackgrounDRb::Rails > attr_accessor :progress, :message, :ids_retrieved > > def do_work(args) > @progress = 0 > @message = args[:message] || "" > @job_completed = false > @hse_notices_retrieved = 0 > puts args[:message] > get_new_ids(args) > end > > def get_new_ids(args) > .... > end > end| > > However, I get NoMethodError (undefined method `ids_retrieved'' for > #<ScrapeWorker:0x2a678b8>) > > Set up a quick unit test, and not surprisingly fails on first respond_to > > | def test_should_respond_to_progress_message_and_hse_notices_retrieved > MiddleMan.new_worker(:class => :scrape_worker, :args => > {:message => "Uh -Oh"}, :job_key => :test_scraper, :ttl => 5) > s = MiddleMan[:test_scraper] > assert s.respond_to?(:progress) > assert s.respond_to?(:message) > assert s.respond_to?(:hse_notices_retrieved) > assert_equal "Uh -Oh", s.message > end| > > I''m sure it must be something really obviously but can''t for the life of > me work out what. Any ideas? > > Thanks in advance > Chris > > p.s. I''m on OS X, though not sure that''s relevant here... > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >-- Charles Brian Quinn self-promotion: www.seebq.com highgroove studios: www.highgroove.com slingshot hosting: www.slingshothosting.com
Frederick Cheung
2006-Oct-12 16:37 UTC
[Backgroundrb-devel] BackgrounDRb newbie stuck at first base. Fresh pair of eyes needed
On 12 Oct 2006, at 16:18, Chris T wrote:> Can''t believe I can''t see the problem here, but after a few hours > bashing my head on a brick wall, going to risk looking stupid by > seeing > if anyone can point out my idiocy (that''s the worst thing about coding > on your own). >Random guess: you haven''t restarted the backgroundrb process since you''ve added the progress method ? Fred
Ezra Zygmuntowicz
2006-Oct-12 18:32 UTC
[Backgroundrb-devel] BackgrounDRb newbie stuck at first base. Fresh pair of eyes needed
On Oct 12, 2006, at 9:37 AM, Frederick Cheung wrote:> > On 12 Oct 2006, at 16:18, Chris T wrote: > >> Can''t believe I can''t see the problem here, but after a few hours >> bashing my head on a brick wall, going to risk looking stupid by >> seeing >> if anyone can point out my idiocy (that''s the worst thing about >> coding >> on your own). >> > Random guess: you haven''t restarted the backgroundrb process since > you''ve added the progress method ? > > FredAlso I am not entirely sure that you can use respond_to? across a drb connection like that. Because drb uses method missing internally to dispatch across the wire it won''t be able to respond_to? what you are trying to do. Is it just the test case that is failing? -EZra
Ezra Zygmuntowicz
2006-Oct-12 19:33 UTC
[Backgroundrb-devel] BackgrounDRb newbie stuck at first base. Fresh pair of eyes needed
On Oct 12, 2006, at 12:28 PM, Chris T wrote:> Ezra Zygmuntowicz wrote: >> >> On Oct 12, 2006, at 9:37 AM, Frederick Cheung wrote: >> >>> >>> On 12 Oct 2006, at 16:18, Chris T wrote: >>> >>>> Can''t believe I can''t see the problem here, but after a few hours >>>> bashing my head on a brick wall, going to risk looking stupid by >>>> seeing >>>> if anyone can point out my idiocy (that''s the worst thing about >>>> coding >>>> on your own). >>>> >>> Random guess: you haven''t restarted the backgroundrb process since >>> you''ve added the progress method ? >>> >>> Fred >> >> >> Also I am not entirely sure that you can use respond_to? >> across a drb connection like that. Because drb uses method missing >> internally to dispatch across the wire it won''t be able to >> respond_to? what you are trying to do. Is it just the test case >> that is failing? >> >> -EZra >> > Ezra > I''ve tried doing this through the console, just to see where the > prob is, but keep having difficulties with all the requires. Do I > need to do all the requires in the test case, including requiring > the worker? Keep getting uninitialized constant... Could that be a > clue, or won''t it work via the console. > Cheers for your help > ChrisChris- It will work fine from the console as long as the backgroundrb server is running before you start script/console then you can just access the MidleMan directly. Make sure you have entirely killed the drb server and then restart it and drop into script/console and try it from there. Does it work if you try to use one of the example workers at all? Have you ever had the plugin working yet and just now its broken or what? Also I see in your unit test that you are testing for hse_notices_retrieved but you didnt make an attr_accessor for it. From what you have showed me I don''t see any reason why it shouldn''t be working. Make sure that you have really killed the server and then restart it and try again. -Ezra
Chris T
2006-Oct-13 09:13 UTC
[Backgroundrb-devel] BackgrounDRb newbie stuck at first base. Fresh pair of eyes needed
Ezra Zygmuntowicz wrote:> > On Oct 12, 2006, at 12:28 PM, Chris T wrote: > >> Ezra Zygmuntowicz wrote: >>> >>> On Oct 12, 2006, at 9:37 AM, Frederick Cheung wrote: >>> >>>> >>>> On 12 Oct 2006, at 16:18, Chris T wrote: >>>> >>>>> Can''t believe I can''t see the problem here, but after a few hours >>>>> bashing my head on a brick wall, going to risk looking stupid by >>>>> seeing >>>>> if anyone can point out my idiocy (that''s the worst thing about >>>>> coding >>>>> on your own). >>>>> >>>> Random guess: you haven''t restarted the backgroundrb process since >>>> you''ve added the progress method ? >>>> >>>> Fred >>> >>> >>> Also I am not entirely sure that you can use respond_to? across >>> a drb connection like that. Because drb uses method missing >>> internally to dispatch across the wire it won''t be able to >>> respond_to? what you are trying to do. Is it just the test case that >>> is failing? >>> >>> -EZra >>> >> Ezra >> I''ve tried doing this through the console, just to see where the prob >> is, but keep having difficulties with all the requires. Do I need to >> do all the requires in the test case, including requiring the worker? >> Keep getting uninitialized constant... Could that be a clue, or won''t >> it work via the console. >> Cheers for your help >> Chris > > Chris- > > It will work fine from the console as long as the backgroundrb > server is running before you start script/console then you can just > access the MidleMan directly. Make sure you have entirely killed the > drb server and then restart it and drop into script/console and try it > from there. Does it work if you try to use one of the example workers > at all? Have you ever had the plugin working yet and just now its > broken or what? Also I see in your unit test that you are testing for > hse_notices_retrieved but you didnt make an attr_accessor for it. From > what you have showed me I don''t see any reason why it shouldn''t be > working. Make sure that you have really killed the server and then > restart it and try again. > > -Ezra >OK. Sorted this now. It was one those those multiple bugs -- where a whole lot of things were not working quite right, and so making it difficult to zero in on the problem. First, the problems were hidden by two things -- I was running autotest in the background, which was of course rerunning the test every time I changed anything. Second, I had got the sleep set to the default of 60, so the worker wasn''t always dead by the time the test was re-run [Note to self: not much point in having TTL less than the sleep time]. Sometime it was, sometime it wasn''t. Result: inconsistency in error messages. Third, when trying different combinations of things, I tried not submitting any args. Result: more apparent (though not actual) weirdness: of course the line @message = args[:message] || "" fails because args is then nil, not an empty Hash, so the setup fails at that point. Hence, why it wasn''t responding to the accessor methods. Finally, I hadn''t really appreciated (i.e. it hadn''t properly sunk in) that you had to restart backgroundrb every time you made a change in the worker class. I thought I was doing it, but wit all the inconsistency, I''m now not 100% sure. Anyway, all working now. For future ref the respond_to? works fine as a way of testing the accessor methods have been loaded OK, and I''d advise anyone who is running autotest to turn it off while debugging worker classes -- the combination of TTL, sleep, quickly running tests, and the need to restart backgroundrb makes life way to messy. Thanks for your help, and thanks for the plugin. Chris p.s. Is it possible to have different configs for development, test and production?
Chris T
2006-Oct-13 09:55 UTC
[Backgroundrb-devel] BackgrounDRb newbie stuck at first base. Fresh pair of eyes needed
Ezra Zygmuntowicz wrote:> > On Oct 12, 2006, at 12:28 PM, Chris T wrote: > >> Ezra Zygmuntowicz wrote: >>> >>> On Oct 12, 2006, at 9:37 AM, Frederick Cheung wrote: >>> >>>> >>>> On 12 Oct 2006, at 16:18, Chris T wrote: >>>> >>>>> Can''t believe I can''t see the problem here, but after a few hours >>>>> bashing my head on a brick wall, going to risk looking stupid by >>>>> seeing >>>>> if anyone can point out my idiocy (that''s the worst thing about >>>>> coding >>>>> on your own). >>>>> >>>> Random guess: you haven''t restarted the backgroundrb process since >>>> you''ve added the progress method ? >>>> >>>> Fred >>> >>> >>> Also I am not entirely sure that you can use respond_to? across >>> a drb connection like that. Because drb uses method missing >>> internally to dispatch across the wire it won''t be able to >>> respond_to? what you are trying to do. Is it just the test case that >>> is failing? >>> >>> -EZra >>> >> Ezra >> I''ve tried doing this through the console, just to see where the prob >> is, but keep having difficulties with all the requires. Do I need to >> do all the requires in the test case, including requiring the worker? >> Keep getting uninitialized constant... Could that be a clue, or won''t >> it work via the console. >> Cheers for your help >> Chris > > Chris- > > It will work fine from the console as long as the backgroundrb > server is running before you start script/console then you can just > access the MidleMan directly. Make sure you have entirely killed the > drb server and then restart it and drop into script/console and try it > from there. Does it work if you try to use one of the example workers > at all? Have you ever had the plugin working yet and just now its > broken or what? Also I see in your unit test that you are testing for > hse_notices_retrieved but you didnt make an attr_accessor for it. From > what you have showed me I don''t see any reason why it shouldn''t be > working. Make sure that you have really killed the server and then > restart it and try again. > > -Ezra >One other thing, if backgroundrb crashes or goes off on one (easy to do when you''re doing screen scraping, even if you are using mocks), rake backgroundrb:stop doesn''t stop the process (although it throws no error or warning). I had to go into OS X''s activity monitor to kill it. Think that was possibly causing some of the erratic behaviour. Too new to OS X to know whether this is a Mac thing, and haven''t had a chance to look into the rake tasks yet, but just thought it was worth reporting. Cheers CT
Reasonably Related Threads
- how about the global data when multiple backgroundrbs ?
- Drb Connection error on multiple dispatch.fcgi ''s
- backgroundrb scalability
- Please help, if @jobs[key].respond_to? :thread is returning false
- Exception when doing DRb remote calls from a BackgrounDRb worker