[Backgroundrb-devel] getting started

Tim Glen tim at pivotib.com
Wed Jan 16 16:33:54 EST 2008


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



More information about the Backgroundrb-devel mailing list