[Backgroundrb-devel] getting started

hemant gethemant at gmail.com
Wed Jan 16 13:15:30 EST 2008


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_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.
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


More information about the Backgroundrb-devel mailing list