[Backgroundrb-devel] getting started

Tim Glen tim at pivotib.com
Wed Jan 16 12:48:08 EST 2008


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


More information about the Backgroundrb-devel mailing list