Hey all, Been reading through all the old posts (and the docs) to familiarize myself but I still feel a bit lost. I''m on trunk and am having a bit of a hard time knowing where to start with the particular I''m trying to solve. So far, I''ve downloaded backgroundrb, done the basic rails setup, created my worker and started it using `script/backgroundrb start`. Here''s the behaviour I''m looking to create: 1. When a file is uploaded, the worker needs to be triggered to start processing the file (this is a 20-60 minute job, depending on the file) 2. The user should be redirected to a page where they can see a status of the processing job (the ideal would be a percentage or status bar but I realize that''s an implementation concern). most importantly, they need to know when it''s been completed. Here are my questions - since this only needs to take place every month or so, I don''t really feel like I need a long-running worker necessarily. From the docs, it seemed like I could call: MiddleMan.ask_work(:worker => :sales_processor, :worker_method => :do_work, :data => @upload.id) In the :do_work method, I''m calling register_status but am receiving nil when I call ask_status I guess I just feel like I''m shooting in the dark here - not sure if i''m going in the right direction at all. Should I be using ask_work with register_status? Perhaps send_request (though I don''t want the http request to wait for the worker to be completed)? Does the worker need to be running on a schedule before I can use either of these? I would appreciate any direction. thanks, tim
Hi Tim, On Jan 12, 2008 2:49 AM, Tim Glen <tim at pivotib.com> wrote:> Hey all, > > Been reading through all the old posts (and the docs) to familiarize > myself but I still feel a bit lost. > > I''m on trunk and am having a bit of a hard time knowing where to start > with the particular I''m trying to solve. > > So far, I''ve downloaded backgroundrb, done the basic rails setup, > created my worker and started it using `script/backgroundrb start`. > Here''s the behaviour I''m looking to create: > 1. When a file is uploaded, the worker needs to be triggered to start > processing the file (this is a 20-60 minute job, depending on the file) > 2. The user should be redirected to a page where they can see a status > of the processing job (the ideal would be a percentage or status bar > but I realize that''s an implementation concern). most importantly, > they need to know when it''s been completed. > > Here are my questions - since this only needs to take place every > month or so, I don''t really feel like I need a long-running worker > necessarily. From the docs, it seemed like I could call: > MiddleMan.ask_work(:worker => :sales_processor, :worker_method > => :do_work, :data => @upload.id) > In the :do_work method, I''m calling register_status but am receiving > nil when I call ask_status > > I guess I just feel like I''m shooting in the dark here - not sure if > i''m going in the right direction at all. Should I be using ask_work > with register_status? Perhaps send_request (though I don''t want the > http request to wait for the worker to be completed)? Does the worker > need to be running on a schedule before I can use either of these? > > I would appreciate any direction.Start your long running task like this: MiddleMan.new_worker(:worker => :sales_processor_worker,:data => @upload.id) # I think, you need _worker there, just check the name thats there in worker class. Whatever name is used # there, you must use it here too. Now in sales_processor_worker class SalesProcessorWorker < BackgrunDRb::MetaWorker set_worker_name :sales_processor_worker set_no_auto_load true # whatever you passed as an :data is available here as an argument def create(args = nil) register_status("Processing started") # do some more processing here end end>From controller get status like this:MiddleMan.ask_status(:worker => :sales_processor_worker) Thats about it. The key is, if you don''t need a perpetually running worker around, disable auto loading of worker and start your worker using MiddleMan.new_worker and then query status. Hope this helps. -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org
Please help me get up and running. If successful, we can turn this thread into
a Getting Started guide to Facebooker.
Here''s what I have:
#ENV[''FACEBOOK_API_KEY''] = ''xxxxx'' # actual
keys here, x''d out for security
#ENV[''FACEBOOK_SECRET_KEY''] = ''xxxxx''
class FacebookController < ApplicationController
ensure_application_is_installed_by_facebook_user
def index
session =
Facebooker::Session.create(ENV[''FACEBOOK_API_KEY''],ENV[''FACEBOOK_SECRET_KEY''])
@user = session.user() # line 12 - Exception here:
Facebooker::Session::MissingOrInvalidParameter
# ...
end
end
Here''s the trace:
Facebooker::Session::MissingOrInvalidParameter (Invalid parameter):
.//vendor/plugins/facebooker/lib/facebooker/parser.rb:322:in
`process''
.//vendor/plugins/facebooker/lib/facebooker/parser.rb:15:in `parse''
.//vendor/plugins/facebooker/lib/facebooker/service.rb:13:in `post''
.//vendor/plugins/facebooker/lib/facebooker/session.rb:328:in
`post''
.//vendor/plugins/facebooker/lib/facebooker/session.rb:135:in
`secure!''
.//vendor/plugins/facebooker/lib/facebooker/session.rb:361:in `uid''
.//vendor/plugins/facebooker/lib/facebooker/session.rb:165:in
`user''
.//app/controllers/facebook_controller.rb:12:in `index''
What am I doing wrong?
Thanks,
Shawn
Hey Shawn, You don''t actually need to create your own session. The before filter will do that for you. In your example you could do @user = session[:facebook_session].user Dave On Jan 15, 2008 1:17 PM, Shawn Van Ittersum <svicalifornia at gmail.com> wrote:> Please help me get up and running. If successful, we can turn this thread into a Getting Started guide to Facebooker. > > Here''s what I have: > > #ENV[''FACEBOOK_API_KEY''] = ''xxxxx'' # actual keys here, x''d out for security > #ENV[''FACEBOOK_SECRET_KEY''] = ''xxxxx'' > > class FacebookController < ApplicationController > ensure_application_is_installed_by_facebook_user > > def index > > session = Facebooker::Session.create(ENV[''FACEBOOK_API_KEY''],ENV[''FACEBOOK_SECRET_KEY'']) > @user = session.user() # line 12 - Exception here: Facebooker::Session::MissingOrInvalidParameter > # ... > end > end > > Here''s the trace: > > Facebooker::Session::MissingOrInvalidParameter (Invalid parameter): > .//vendor/plugins/facebooker/lib/facebooker/parser.rb:322:in `process'' > .//vendor/plugins/facebooker/lib/facebooker/parser.rb:15:in `parse'' > .//vendor/plugins/facebooker/lib/facebooker/service.rb:13:in `post'' > .//vendor/plugins/facebooker/lib/facebooker/session.rb:328:in `post'' > .//vendor/plugins/facebooker/lib/facebooker/session.rb:135:in `secure!'' > .//vendor/plugins/facebooker/lib/facebooker/session.rb:361:in `uid'' > .//vendor/plugins/facebooker/lib/facebooker/session.rb:165:in `user'' > .//app/controllers/facebook_controller.rb:12:in `index'' > > What am I doing wrong? > > Thanks, > Shawn > _______________________________________________ > Facebooker-talk mailing list > Facebooker-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/facebooker-talk >
Thanks, Dave! Shawn On Tue, 15 Jan 2008 13:25:25 -0700, David Clements wrote:> Hey Shawn, > > You don''t actually need to create your own session. The before filter > will do that for you. > In your example you could do > > @user = session[:facebook_session].user > > > Dave > > On Jan 15, 2008 1:17 PM, Shawn Van Ittersum <svicalifornia at gmail.com> wrote: >> Please help me get up and running. If successful, we can turn this >> thread into a Getting Started guide to Facebooker. >> >> Here''s what I have: >> >> #ENV[''FACEBOOK_API_KEY''] = ''xxxxx'' # actual keys here, x''d out for security >> #ENV[''FACEBOOK_SECRET_KEY''] = ''xxxxx'' >> >> class FacebookController < ApplicationController >> ensure_application_is_installed_by_facebook_user >> >> def index >> >> session = >> Facebooker::Session.create(ENV[''FACEBOOK_API_KEY''],ENV[''FACEBOOK_SECRET_KEY'']) >> @user = session.user() # line 12 - Exception here: >> Facebooker::Session::MissingOrInvalidParameter >> # ... >> end >> end >> >> Here''s the trace: >> >> Facebooker::Session::MissingOrInvalidParameter (Invalid parameter): >> .//vendor/plugins/facebooker/lib/facebooker/parser.rb:322:in `process'' >> .//vendor/plugins/facebooker/lib/facebooker/parser.rb:15:in `parse'' >> .//vendor/plugins/facebooker/lib/facebooker/service.rb:13:in `post'' >> .//vendor/plugins/facebooker/lib/facebooker/session.rb:328:in `post'' >> .//vendor/plugins/facebooker/lib/facebooker/session.rb:135:in `secure!'' >> .//vendor/plugins/facebooker/lib/facebooker/session.rb:361:in `uid'' >> .//vendor/plugins/facebooker/lib/facebooker/session.rb:165:in `user'' >> .//app/controllers/facebook_controller.rb:12:in `index'' >> >> What am I doing wrong? >> >> Thanks, >> Shawn >> _______________________________________________ >> Facebooker-talk mailing list >> Facebooker-talk at rubyforge.org >> http://rubyforge.org/mailman/listinfo/facebooker-talk >>
Hey there, On 11-Jan-08, at 5:06 PM, hemant wrote:> Hi Tim, > > On Jan 12, 2008 2:49 AM, Tim Glen <tim at pivotib.com> wrote: >> <removed snippet> >> >> So far, I''ve downloaded backgroundrb, done the basic rails setup, >> created my worker and started it using `script/backgroundrb start`. >> Here''s the behaviour I''m looking to create: >> 1. When a file is uploaded, the worker needs to be triggered to start >> processing the file (this is a 20-60 minute job, depending on the >> file) >> 2. The user should be redirected to a page where they can see a >> status >> of the processing job (the ideal would be a percentage or status bar >> but I realize that''s an implementation concern). most importantly, >> they need to know when it''s been completed. >> >> <removed snippet> > > Start your long running task like this: > > > MiddleMan.new_worker(:worker => :sales_processor_worker,:data => > @upload.id) > # I think, you need _worker there, just check the name thats there in > worker class. Whatever name is used > # there, you must use it here too. > > Now in sales_processor_worker > > class SalesProcessorWorker < BackgrunDRb::MetaWorker > set_worker_name :sales_processor_worker > set_no_auto_load true > # whatever you passed as an :data is available here as an argument > def create(args = nil) > register_status("Processing started") > # do some more processing here > end > end > > From controller get status like this: > > MiddleMan.ask_status(:worker => :sales_processor_worker) > > Thats about it. The key is, if you don''t need a perpetually running > worker around, disable auto loading of worker and start your worker > using MiddleMan.new_worker and then query status. Hope this helps.okay, cool. I''ve settled in the 1.0.1 release and am using that now rather than trunk. A few followup questions: 1. should my new_worker call include a :job_key? There does exist the possibility for more than one worker to be created at a time. If so, does the ask_status differentiate between the workers? 2. What''s the best way to "exit" from a worker - can I just call exit at the end or should I call delete_worker when it''s complete. It _seems_ like if I just exit, the 11006 port stays open after each worker is completed and no longer running (according to `ps aux`), which doesn''t seem right to me. These ports stay open even after I `script/backgroundrb stop`. Since there''s no process attached to them, I''m unsure how to close the ports manually: timg:marks tim$ netstat -at | grep 11006 tcp6 0 0 localhost.51482 localhost.11006 TIME_WAIT tcp6 0 0 localhost.51483 localhost.11006 TIME_WAIT tcp6 0 0 localhost.51484 localhost.11006 TIME_WAIT tcp6 0 0 localhost.51485 localhost.11006 TIME_WAIT tcp6 0 0 localhost.51486 localhost.11006 TIME_WAIT tcp6 0 0 localhost.51487 localhost.11006 TIME_WAIT 3. I''m using rspec as a specing framework. From a relatively recent thread (see here: http://rubyforge.org/pipermail/backgroundrb-devel/2008-January/001280.html) , my understanding was to leave the ":environment: development" key in my backgroundrb.yml file and just put RAILS_ENV="test" in my bdrb_spec_helper.rb file (virtually identical to the bdrb_test_helper file). I''ve done this, but when I run `script/backgroundrb start`, it still inherits the development environment and therefore can''t do any db interaction. I''ve been reduced to changing my config file whenever I want to change from development to test or vice versa. Am I meant to start up backgroundrb from within the test environment somehow? Hopefully this all makes sense. take care, tim
Hi Tim On Jan 16, 2008 11:18 PM, Tim Glen <tim at pivotib.com> wrote: <snip>> A few followup questions: > 1. should my new_worker call include a :job_key? There does exist the > possibility for more than one worker to be created at a time. If so, > does the ask_status differentiate between the workers?It sure differentiate between workers.You can include job_key if you want same worker to be running in two different processes.> 2. What''s the best way to "exit" from a worker - can I just call exit > at the end or should I call delete_worker when it''s complete. It > _seems_ like if I just exit, the 11006 port stays open after each > worker is completed and no longer running (according to `ps aux`), > which doesn''t seem right to me. These ports stay open even after I > `script/backgroundrb stop`. Since there''s no process attached to them, > I''m unsure how to close the ports manually: > timg:marks tim$ netstat -at | grep 11006 > tcp6 0 0 localhost.51482 localhost.11006 > TIME_WAIT > tcp6 0 0 localhost.51483 localhost.11006 > TIME_WAIT > tcp6 0 0 localhost.51484 localhost.11006 > TIME_WAIT > tcp6 0 0 localhost.51485 localhost.11006 > TIME_WAIT > tcp6 0 0 localhost.51486 localhost.11006 > TIME_WAIT > tcp6 0 0 localhost.51487 localhost.11006 > TIME_WAITYou can call "exit" from a worker. However, when you call exit on a worker, only that worker dies, master process stays, for handling more requests. However, your last bit of information about port still being used even after bdrb is completely stopped is weird and could be OS specific. I will investigate further.> 3. I''m using rspec as a specing framework. From a relatively recent > thread (see here: http://rubyforge.org/pipermail/backgroundrb-devel/2008-January/001280.html) > , my understanding was to leave the ":environment: development" key in > my backgroundrb.yml file and just put RAILS_ENV="test" in my > bdrb_spec_helper.rb file (virtually identical to the bdrb_test_helper > file). I''ve done this, but when I run `script/backgroundrb start`, it > still inherits the development environment and therefore can''t do any > db interaction. I''ve been reduced to changing my config file whenever > I want to change from development to test or vice versa. Am I meant to > start up backgroundrb from within the test environment somehow?You mean to say that, even in test mode, development environment is loaded? There is something weird here, that helper shouldn''t load any of backgroundrb files and is just for enabling testing of workers. -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org
Hi Hemant, On 16-Jan-08, at 1:15 PM, hemant wrote:> Hi Tim > > On Jan 16, 2008 11:18 PM, Tim Glen <tim at pivotib.com> wrote: > <snip> >> A few followup questions: >> 1. should my new_worker call include a :job_key? There does exist the >> possibility for more than one worker to be created at a time. If so, >> does the ask_status differentiate between the workers? > > It sure differentiate between workers.You can include job_key if you > want same worker to be running in two different processes.k cool. I had assumed so, but wanted to make sure.>> 2. What''s the best way to "exit" from a worker - can I just call exit >> at the end or should I call delete_worker when it''s complete. It >> _seems_ like if I just exit, the 11006 port stays open after each >> worker is completed and no longer running (according to `ps aux`), >> which doesn''t seem right to me. These ports stay open even after I >> `script/backgroundrb stop`. Since there''s no process attached to >> them, >> I''m unsure how to close the ports manually: >> timg:marks tim$ netstat -at | grep 11006 >> tcp6 0 0 localhost.51482 localhost.11006 >> TIME_WAIT >> tcp6 0 0 localhost.51483 localhost.11006 >> TIME_WAIT >> tcp6 0 0 localhost.51484 localhost.11006 >> TIME_WAIT >> tcp6 0 0 localhost.51485 localhost.11006 >> TIME_WAIT >> tcp6 0 0 localhost.51486 localhost.11006 >> TIME_WAIT >> tcp6 0 0 localhost.51487 localhost.11006 >> TIME_WAIT > > You can call "exit" from a worker. However, when you call exit on a > worker, only that worker dies, master process stays, for handling more > requests.This I expected, yes. I just looked more at this - these ports stay open as long as the master_worker is still running. Those ports actually remain open _after_ I have stopped the master worker (using either `script/backgroundrb stop` or `kill`, but seem to close themselves after a few minutes (I haven''t been able to get more accurate than that). If the worker-specific ports are _meant_ to hang around while the master_worker is running, that''s all good. Also, if they just take a few minutes to get "reaped" after the process is completed, that''s okay too.> However, your last bit of information about port still being used even > after bdrb is completely stopped is weird and could be OS specific. I > will investigate further.Specifically, i''m developing on osx. The production machine is also os x or I would be less concerned about it. Again - this could be expected behaviour, but it seemed odd to me>> 3. I''m using rspec as a specing framework. From a relatively recent >> thread (see here: http://rubyforge.org/pipermail/backgroundrb-devel/2008-January/001280.html) >> , my understanding was to leave the ":environment: development" key >> in >> my backgroundrb.yml file and just put RAILS_ENV="test" in my >> bdrb_spec_helper.rb file (virtually identical to the bdrb_test_helper >> file). I''ve done this, but when I run `script/backgroundrb start`, it >> still inherits the development environment and therefore can''t do any >> db interaction. I''ve been reduced to changing my config file whenever >> I want to change from development to test or vice versa. Am I meant >> to >> start up backgroundrb from within the test environment somehow? > > You mean to say that, even in test mode, development environment is > loaded? > There is something weird here, that helper shouldn''t load any of > backgroundrb files and is just for enabling testing of workers.yes, I''m saying that having RAILS_ENV = ''test'' at the top of my test helper file seems to make no difference to the environment. Let me clarify what I''m doing (and my assumptions) a little further. First, my assumption is that I need to have the master_worker running (through `script/backgroundrb start`) in order to run my tests. When it''s not, I get a backgroundrb connection error so that seems valid. Also, I am testing using the MiddleMan object like so: MiddleMan.new_worker(:worker => :sales_processor_worker, :job_key => "sales_processor_#{@upload.id }", :data => @upload.id) MiddleMan.ask_status(:worker => :sales_processor_worker, :job_key => "sales_processor_#{@upload.id}").should_not be_nil there are slightly more complex things that I''m doing in the testing, but that''s the gist of it. Is there a better way? I can''t run the Worker directly from within the test since the Worker contains an `exit` call. If you want to see actual spec, code, I can send it. I _could_ stub out the MiddleMan functionality but wanted to see actual functionality in my specs since it was also part of the discovery process for me. take care, tim
Hi Tim, On Wed, 2008-01-16 at 16:33 -0500, Tim Glen wrote: <snip>> > yes, I''m saying that having RAILS_ENV = ''test'' at the top of my test > helper file seems to make no difference to the environment. Let me > clarify what I''m doing (and my assumptions) a little further. First, > my assumption is that I need to have the master_worker running > (through `script/backgroundrb start`) in order to run my tests. When > it''s not, I get a backgroundrb connection error so that seems valid. > Also, I am testing using the MiddleMan object like so: > MiddleMan.new_worker(:worker => :sales_processor_worker, :job_key => "sales_processor_#{@upload.id > }", :data => @upload.id) > MiddleMan.ask_status(:worker => :sales_processor_worker, :job_key => > "sales_processor_#{@upload.id}").should_not be_nil > > there are slightly more complex things that I''m doing in the testing, > but that''s the gist of it. Is there a better way? I can''t run the > Worker directly from within the test since the Worker contains an > `exit` call. If you want to see actual spec, code, I can send it. I > _could_ stub out the MiddleMan functionality but wanted to see actual > functionality in my specs since it was also part of the discovery > process for me.You don''t need to have the master process running, when you are doing testing. The idea is that helper should abstract away all the network IO stuff. Can I see your spec helper code?
I''m just getting started with Backgroundrb and I''m having a
lot of
problems. First of all, whenever I try to start or execute a worker I
get the following error:
BackgrounDRb::BdrbConnError (Not able to connect):
.//vendor/plugins/backgroundrb/lib/backgroundrb.rb:47:in
`new_worker''
.//app/controllers/testdrb_controller.rb:13:in `do_fib''
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/base.rb:1095:in
`send''
[...snip...]
I''m using rails version 1.2.6 and ruby 1.8.6. My backgroundrb.yaml
looks like this:
---
:backgroundrb:
:port: 11006
:ip: 0.0.0.0
I am starting the server for my app first and then running
''script/backgroundrb start'' afterwards. I''m just
testing out
backgroundrb to get a feel of it so my app is pretty simple. A number
is selected from a drop down and the user presses a ''go''
button
causing the worker to calculate the selected number''s fibonacci number
(just needed something long running).
Any help much appreciated.
Rich
On Wed, Feb 13, 2008 at 3:36 AM, Richard Everhart <rich.everhart at gmail.com> wrote:> I''m just getting started with Backgroundrb and I''m having a lot of > problems. First of all, whenever I try to start or execute a worker I > get the following error: > > BackgrounDRb::BdrbConnError (Not able to connect): > .//vendor/plugins/backgroundrb/lib/backgroundrb.rb:47:in `new_worker'' > .//app/controllers/testdrb_controller.rb:13:in `do_fib'' > /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/base.rb:1095:in > `send'' > [...snip...] > > I''m using rails version 1.2.6 and ruby 1.8.6. My backgroundrb.yaml > looks like this: > --- > :backgroundrb: > :port: 11006 > :ip: 0.0.0.0 > > I am starting the server for my app first and then running > ''script/backgroundrb start'' afterwards. I''m just testing out > backgroundrb to get a feel of it so my app is pretty simple. A number > is selected from a drop down and the user presses a ''go'' button > causing the worker to calculate the selected number''s fibonacci number > (just needed something long running). > > Any help much appreciated.You are running trunk version of library right? Also, probably bdrb server is not starting up for you. So make sure, backgroundrb server is running. I have collected some best practices for getting up and running with bdrb. http://gnufied.org/2008/02/12/backgroundrb-best-practises/
I upgraded ruby right before I wrote my original message and that was
causing some problems. That''s fixed but I still get the ''Not
able to
connect'' error. In backgroundrb_server.log there seem to really be
two errors:
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require'': no such file to load -- (LoadError)
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require''
from
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in
`require''
from
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in
`new_constants_in''
from
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in
`require''
from
/home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/packet_master.rb:113:in
`start_worker''
[...snip...]
/home/reverhart/drb_test/vendor/plugins/backgroundrb/lib/../framework/nbio.rb:24:in
`read_data'': Packet::DisconnectError (Packet::DisconnectError)
from
/home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/worker.rb:47:in
`handle_internal_messages''
from
/home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/core.rb:154:in
`start_reactor''
[...snip...]
The first error seems to be due to a ruby and/or rails configuration
error. However, I''ve seen this error before, and the
''--'' in the
error message is usually followed by the name of the file that can''t
be loaded.
Thanks for your help!
Rich
On Wed, Feb 13, 2008 at 7:19 AM, Richard Everhart <rich.everhart at gmail.com> wrote:> > I upgraded ruby right before I wrote my original message and that was > causing some problems. That''s fixed but I still get the ''Not able to > connect'' error. In backgroundrb_server.log there seem to really be > two errors: > > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require'': no such file to load -- (LoadError) > from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require'' > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > `require'' > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in > `new_constants_in'' > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > `require'' > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/packet_master.rb:113:in > `start_worker'' > [...snip...] > /home/reverhart/drb_test/vendor/plugins/backgroundrb/lib/../framework/nbio.rb:24:in > `read_data'': Packet::DisconnectError (Packet::DisconnectError) > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/worker.rb:47:in > `handle_internal_messages'' > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/core.rb:154:in > `start_reactor'' > [...snip...] > > The first error seems to be due to a ruby and/or rails configuration > error. However, I''ve seen this error before, and the ''--'' in the > error message is usually followed by the name of the file that can''t > be loaded. >Did you define a worker before starting backgroundrb server? Above error is because, bdrb is not able to load defined worker. If you have the worker defined can we see the code of the worker.
On Feb 12, 2008 6:02 PM, hemant <gethemant at gmail.com> wrote:> > On Wed, Feb 13, 2008 at 7:19 AM, Richard Everhart > <rich.everhart at gmail.com> wrote: > > > > I upgraded ruby right before I wrote my original message and that was > > causing some problems. That''s fixed but I still get the ''Not able to > > connect'' error. In backgroundrb_server.log there seem to really be > > two errors: > > > > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `gem_original_require'': no such file to load -- (LoadError) > > from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require'' > > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > > `require'' > > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in > > `new_constants_in'' > > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > > `require'' > > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/packet_master.rb:113:in > > `start_worker'' > > [...snip...] > > /home/reverhart/drb_test/vendor/plugins/backgroundrb/lib/../framework/nbio.rb:24:in > > `read_data'': Packet::DisconnectError (Packet::DisconnectError) > > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/worker.rb:47:in > > `handle_internal_messages'' > > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/core.rb:154:in > > `start_reactor'' > > [...snip...] > > > > The first error seems to be due to a ruby and/or rails configuration > > error. However, I''ve seen this error before, and the ''--'' in the > > error message is usually followed by the name of the file that can''t > > be loaded. > > > > Did you define a worker before starting backgroundrb server? Above > error is because, bdrb is not able to load defined worker. > If you have the worker defined can we see the code of the worker. >Here is my controller and worker: class TestdrbController < ApplicationController def do_fib puts ">>> do_fib: #{params[:input]}" session[:job_key] = MiddleMan.new_worker(:class => :fibonacci_worker, :data => params[:input]) puts "Job key: #{session[:job_key]}" MiddleMan.send_request(:worker => :fibonacci_worker, :worker_method => :do_work, :data => params[:input]) puts "<<< do_fib" render :action => ''result'' end def result puts ">>> result" MiddleMan.delete_worker(:worker => :fibonacci_worker, :job_key => session[:job_key]) puts "<<< result" end end class FibonacciWorker < BackgrounDRb::MetaWorker include Fibonacci set_worker_name :fibonacci_worker set_no_auto_load true def create(args = nil) logger.info("Worker create: ''#{args}''") register_status("Processing started") n = args.to_i logger.info("Worker result: #{f(n)}") end def do_work(data) logger.info ">>> do_work" result = f(data.to_i) logger.info "Worker result: #{result}" return result end end Thanks again. Richard
Hi, On Tue, 2008-02-12 at 22:47 -0800, Richard Everhart wrote:> On Feb 12, 2008 6:02 PM, hemant <gethemant at gmail.com> wrote: > > > > On Wed, Feb 13, 2008 at 7:19 AM, Richard Everhart > > <rich.everhart at gmail.com> wrote: > > > > > > I upgraded ruby right before I wrote my original message and that was > > > causing some problems. That''s fixed but I still get the ''Not able to > > > connect'' error. In backgroundrb_server.log there seem to really be > > > two errors: > > > > > > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `gem_original_require'': no such file to load -- (LoadError) > > > from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require'' > > > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > > > `require'' > > > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in > > > `new_constants_in'' > > > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > > > `require'' > > > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/packet_master.rb:113:in > > > `start_worker'' > > > [...snip...] > > > /home/reverhart/drb_test/vendor/plugins/backgroundrb/lib/../framework/nbio.rb:24:in > > > `read_data'': Packet::DisconnectError (Packet::DisconnectError) > > > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/worker.rb:47:in > > > `handle_internal_messages'' > > > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/core.rb:154:in > > > `start_reactor'' > > > [...snip...] > > > > > > The first error seems to be due to a ruby and/or rails configuration > > > error. However, I''ve seen this error before, and the ''--'' in the > > > error message is usually followed by the name of the file that can''t > > > be loaded. > > > > > > > Did you define a worker before starting backgroundrb server? Above > > error is because, bdrb is not able to load defined worker. > > If you have the worker defined can we see the code of the worker. > > > > Here is my controller and worker: > > class TestdrbController < ApplicationController > def do_fib > puts ">>> do_fib: #{params[:input]}" > > session[:job_key] = MiddleMan.new_worker(:class => > :fibonacci_worker, :data => params[:input]) > > puts "Job key: #{session[:job_key]}" > > MiddleMan.send_request(:worker => :fibonacci_worker, > :worker_method => :do_work, :data => params[:input]) > > puts "<<< do_fib" > > render :action => ''result'' > end > > def result > puts ">>> result" > MiddleMan.delete_worker(:worker => :fibonacci_worker, :job_key => > session[:job_key]) > puts "<<< result" > end > endAlthough this is not related to your problem, but above controller code has a bit of a problem, when you are not passing any job_key while starting the worker via new_worker method, no job_key will be used and while deleting the worker or invoking a task on the worker you should not use job_key, if you haven''t specified a job_key while creating the worker.> > class FibonacciWorker < BackgrounDRb::MetaWorker > include Fibonacci > > set_worker_name :fibonacci_worker > set_no_auto_load true > > def create(args = nil) > logger.info("Worker create: ''#{args}''") > > register_status("Processing started") > > n = args.to_i > logger.info("Worker result: #{f(n)}") > end > > def do_work(data) > logger.info ">>> do_work" > > result = f(data.to_i) > logger.info "Worker result: #{result}" > > return result > end > endI took above worker code and created new rails application, checked out bdrb code from trunk at devjavu and i was able to start bdrb without problems. In a nutshell, I am unable to reproduce this problem. Now, can you zip and send me your application through mail, so as I can see whats wrong there?
Thanks, Hemant. I made the change related to the job key and I''m not getting a value back from new_worker. However, the ''not able to connect error'' is on going. My zipped up app is attached. Thanks for helping me out. Rich On Wed, Feb 13, 2008 at 1:46 AM, hemant kumar <gethemant at gmail.com> wrote:> Hi, > > > > On Tue, 2008-02-12 at 22:47 -0800, Richard Everhart wrote: > > On Feb 12, 2008 6:02 PM, hemant <gethemant at gmail.com> wrote: > > > > > > On Wed, Feb 13, 2008 at 7:19 AM, Richard Everhart > > > <rich.everhart at gmail.com> wrote: > > > > > > > > I upgraded ruby right before I wrote my original message and that was > > > > causing some problems. That''s fixed but I still get the ''Not able to > > > > connect'' error. In backgroundrb_server.log there seem to really be > > > > two errors: > > > > > > > > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `gem_original_require'': no such file to load -- (LoadError) > > > > from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require'' > > > > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > > > > `require'' > > > > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in > > > > `new_constants_in'' > > > > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in > > > > `require'' > > > > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/packet_master.rb:113:in > > > > `start_worker'' > > > > [...snip...] > > > > /home/reverhart/drb_test/vendor/plugins/backgroundrb/lib/../framework/nbio.rb:24:in > > > > `read_data'': Packet::DisconnectError (Packet::DisconnectError) > > > > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/worker.rb:47:in > > > > `handle_internal_messages'' > > > > from /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/core.rb:154:in > > > > `start_reactor'' > > > > [...snip...] > > > > > > > > The first error seems to be due to a ruby and/or rails configuration > > > > error. However, I''ve seen this error before, and the ''--'' in the > > > > error message is usually followed by the name of the file that can''t > > > > be loaded. > > > > > > > > > > Did you define a worker before starting backgroundrb server? Above > > > error is because, bdrb is not able to load defined worker. > > > If you have the worker defined can we see the code of the worker. > > > > > > > Here is my controller and worker: > > > > class TestdrbController < ApplicationController > > def do_fib > > puts ">>> do_fib: #{params[:input]}" > > > > session[:job_key] = MiddleMan.new_worker(:class => > > :fibonacci_worker, :data => params[:input]) > > > > puts "Job key: #{session[:job_key]}" > > > > MiddleMan.send_request(:worker => :fibonacci_worker, > > :worker_method => :do_work, :data => params[:input]) > > > > puts "<<< do_fib" > > > > render :action => ''result'' > > end > > > > def result > > puts ">>> result" > > MiddleMan.delete_worker(:worker => :fibonacci_worker, :job_key => > > session[:job_key]) > > puts "<<< result" > > end > > end > > Although this is not related to your problem, but above controller code > has a bit of a problem, when you are not passing any job_key while > starting the worker via new_worker method, no job_key will be used and > while deleting the worker or invoking a task on the worker you should > not use job_key, if you haven''t specified a job_key while creating the > worker. > > > > > > class FibonacciWorker < BackgrounDRb::MetaWorker > > include Fibonacci > > > > set_worker_name :fibonacci_worker > > set_no_auto_load true > > > > def create(args = nil) > > logger.info("Worker create: ''#{args}''") > > > > register_status("Processing started") > > > > n = args.to_i > > logger.info("Worker result: #{f(n)}") > > end > > > > def do_work(data) > > logger.info ">>> do_work" > > > > result = f(data.to_i) > > logger.info "Worker result: #{result}" > > > > return result > > end > > end > > I took above worker code and created new rails application, checked out > bdrb code from trunk at devjavu and i was able to start bdrb without > problems. In a nutshell, I am unable to reproduce this problem. Now, can > you zip and send me your application through mail, so as I can see whats > wrong there? > > >-------------- next part -------------- A non-text attachment was scrubbed... Name: drb_test01.zip Type: application/zip Size: 385132 bytes Desc: not available Url : http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080214/972cad18/attachment-0001.zip
On Fri, Feb 15, 2008 at 4:15 AM, Richard Everhart <rich.everhart at gmail.com> wrote:> Thanks, Hemant. I made the change related to the job key and I''m not > getting a value back from new_worker. However, the ''not able to > connect error'' is on going. > > My zipped up app is attached. Thanks for helping me out. >First Problems with your controller code: You have line: session[:job_key] = MiddleMan.new_worker(:class => :fibonacci_worker, :job_key => ''the_key'', :data => params[:input]) Please note that, it should be :worker not :class, so please change the line to: session[:job_key] = MiddleMan.new_worker(:worker => :fibonacci_worker, :job_key => ''the_key'', :data => params[:input]) Now, You have line: MiddleMan.send_request(:worker => :fibonacci_worker, :worker_method => :do_work, :data => params[:input]) Again, as i said earlier, when you are creating a worker with a "job_key" you *must* always access that instance of worker with the same job key and hence it should be: MiddleMan.send_request(:worker => :fibonacci_worker, :worker_method => :do_work, :data => params[:input], :job_key => session[:job_key]) Your worker code is perfectly fine and should work as it. Also, update your plugin from trunk and remove "backgroundrb" script present in script directory and restart the server and try now. It will work. -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org
Changing ''class'' to ''worker'' in new_worker seemed to get things going. I can see that after new_worker is called the worker''s create method is then called. This only seems to work once. After the first time, I get the following error: You have a nil object when you didn''t expect it! The error occurred while evaluating nil.send_request /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/packet_master.rb:43:in `ask_worker'' /home/reverhart/drb_test/vendor/plugins/backgroundrb/server/master_worker.rb:76:in `process_work'' /home/reverhart/drb_test/vendor/plugins/backgroundrb/server/master_worker.rb:34:in `receive_data'' /home/reverhart/drb_test/vendor/plugins/backgroundrb/lib/../framework/bin_parser.rb:29:in `call'' /home/reverhart/drb_test/vendor/plugins/backgroundrb/lib/../framework/bin_parser.rb:29:in `extract'' /home/reverhart/drb_test/vendor/plugins/backgroundrb/server/master_worker.rb:30:in `receive_data'' /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/core.rb:195:in `read_external_socket'' /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/core.rb:187:in `handle_external_messages'' [...snip...] Eventually, what I would really like to do is return a value back to the browser. send_request is documented to do this but the browser just hangs and I really can''t tell if the the worker method (do_work in this is being executed). While the work is being executed by the worker I''d like to display a progress bar or a busy indicator, both of which I''ve seen examples. But, it seems that the do_work method is never called, even when calling ask_work, which is not supposed to block. I have not tried out the latest version so I''m not sure if that will change things. Thanks a lot! Rich On Thu, Feb 14, 2008 at 3:24 PM, hemant <gethemant at gmail.com> wrote:> On Fri, Feb 15, 2008 at 4:15 AM, Richard Everhart > > <rich.everhart at gmail.com> wrote: > > > Thanks, Hemant. I made the change related to the job key and I''m not > > getting a value back from new_worker. However, the ''not able to > > connect error'' is on going. > > > > My zipped up app is attached. Thanks for helping me out. > > > > First Problems with your controller code: > > You have line: > > > session[:job_key] = MiddleMan.new_worker(:class => :fibonacci_worker, > :job_key => ''the_key'', :data => params[:input]) > > Please note that, it should be :worker not :class, so please change the line to: > session[:job_key] = MiddleMan.new_worker(:worker => > :fibonacci_worker, :job_key => ''the_key'', :data => params[:input]) > > Now, You have line: > > > MiddleMan.send_request(:worker => :fibonacci_worker, :worker_method > => :do_work, :data => params[:input]) > > Again, as i said earlier, when you are creating a worker with a > "job_key" you *must* always access that instance of worker with the > same job key and hence it should be: > > > MiddleMan.send_request(:worker => :fibonacci_worker, :worker_method > => :do_work, :data => params[:input], :job_key => session[:job_key]) > > Your worker code is perfectly fine and should work as it. Also, update > your plugin from trunk and remove "backgroundrb" script present in > script directory and restart the server and try now. It will work. > > > -- > Let them talk of their oriental summer climes of everlasting > conservatories; give me the privilege of making my own summer with my > own coals. > > http://gnufied.org >
On Fri, Feb 15, 2008 at 7:11 AM, Richard Everhart <rich.everhart at gmail.com> wrote:> Changing ''class'' to ''worker'' in new_worker seemed to get things going. > I can see that after new_worker is called the worker''s create method > is then called. This only seems to work once. After the first time, I > get the following error: > > You have a nil object when you didn''t expect it! > The error occurred while evaluating nil.send_request > /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/packet_master.rb:43:in > `ask_worker'' > /home/reverhart/drb_test/vendor/plugins/backgroundrb/server/master_worker.rb:76:in > `process_work'' > /home/reverhart/drb_test/vendor/plugins/backgroundrb/server/master_worker.rb:34:in > `receive_data'' > /home/reverhart/drb_test/vendor/plugins/backgroundrb/lib/../framework/bin_parser.rb:29:in > `call'' > /home/reverhart/drb_test/vendor/plugins/backgroundrb/lib/../framework/bin_parser.rb:29:in > `extract'' > /home/reverhart/drb_test/vendor/plugins/backgroundrb/server/master_worker.rb:30:in > `receive_data'' > /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/core.rb:195:in > `read_external_socket'' > /home/reverhart/drb_test/vendor/plugins/backgroundrb/framework/core.rb:187:in > `handle_external_messages'' > [...snip...] > > Eventually, what I would really like to do is return a value back to > the browser. send_request is documented to do this but the browser > just hangs and I really can''t tell if the the worker method (do_work > in this is being executed). While the work is being executed by the > worker I''d like to display a progress bar or a busy indicator, both of > which I''ve seen examples. But, it seems that the do_work method is > never called, even when calling ask_work, which is not supposed to > block. > > I have not tried out the latest version so I''m not sure if that will > change things. Thanks a lot! >I wanted to ask, are you sure you want to create new workers on each request? Can''t you handle all the requests in the same instance of worker. Also, send_request blocks until bdrb returns a response and thats why your browser is hung. A better approach is to use register_status in your worker and invoke ask_status in rails code. Again, please read the README carefully from start to beginning. Also, use following links for debugging: http://gnufied.org/2008/02/12/backgroundrb-best-practises/ http://www.johnyerhot.com/2008/02/11/debugging-backgroundrb/