[Backgroundrb-devel] strange deployment issue

Jason Lee jasonlee9 at gmail.com
Thu May 1 10:29:50 EDT 2008


Solved.

So I basically followed Adam's advice and have my deploy copying a
different backgroundrb.yml file out based on the deploy.

One thing that was a little puzzling was the whole worker thread
process and how it picked up the environment. I noticed a few things,
but I'm not sure if I'm totally correct about them as I haven't really
delved into the codebase.

1. Seems each worker process/run picks up the config. At first glance
I thought "hmm, why re-load the config every time?". I'll probably be
running multiple workers - maybe half a dozen - doing various things
and the config reload seems like an unnecessary hit. *However*, I
didn't write BRb and I'm sure there's obviously a reason why this is
happening and I just don't know it yet.

2. The fact that the config is picked up on each run, overrides any
env I pass in from the command line or from any automated
rake/execution task. I put debug in various places, kicked off the
server with the rails env set and saw that the first run picked up the
env. Every run after, defaulted to development.

So anyway, this isn't a critique, just observations. I'll be putting
my system into a real production env in a few weeks and I'm glad BRb
exists at all - keeps me from having to write yet another
component/service. :)

Thanks for the replies, it's been very helpful!

- jason

On Wed, Apr 30, 2008 at 2:22 PM, Jason Lee <jasonlee9 at gmail.com> wrote:
> Adam,
>
>  Thanks for the reply. I'll have to see if I can play around with the
>  yml file. I definitely cannot use the scheduler definition as it was
>  very unreliable for the tasks I needed to launch. If I can just get
>  the environments to come up without any of the other config, I'll be
>  good.
>
>  I'll post back my solution when I find it.
>
>  Thanks again,
>
>  - jason
>
>
>
>  On Wed, Apr 30, 2008 at 10:35 AM, Adam Williams <adam at thewilliams.ws> wrote:
>  > So, there is some serious confusion about this in the code. I now know of
>  > two other folks (one you, Jason) who struggled with this besides me.
>  >
>  >  I solved it by having a shared/config/backgroundrb.yml on the server, which
>  > we link into config of the app on deploy (capistrano). It looks like this:
>  >
>  >  :backgroundrb:
>  >   :port: 11006
>  >
>  >   :ip: 0.0.0.0
>  >   :environment: staging
>  >   :lazy_load: true
>  >   :debug_log: true
>  >
>  >  :schedules:
>  >   :notification:
>  >     :deliver_event_reminders:
>  >       :trigger_args: 0 */3 * * * * *
>  >
>  >  As you can see, we have the environment in the config. The code in
>  > meta_worker obviously disrespects -e. Now, you ALSO need to pass -e staging,
>  > so that when Rails boots, it has the correct environment. Here is our init.d
>  > line:
>  >
>  >   /var/www/apps/railsapplication/current/script/backgroundrb "$1" -e staging
>  > >> /var/log/backgroundrb
>  >
>  >  I may patch this at some point, but it's already eaten a bit too much time
>  > (not you, but solving it originally).
>  >
>  >    aiwilliams
>  >
>  >
>  >
>  >  On Apr 30, 2008, at 12:49 PM, Jason Lee wrote:
>  >
>  >
>  > >
>  > >
>  > >
>  > > So I tried this and my debug still says the env is development..
>  > >
>  > > Guess I'll have to start hacking to see why this is..
>  > >
>  > > - jason
>  > >
>  > > On Wed, Apr 30, 2008 at 8:15 AM, Stevie Clifton <stevie at slowbicycle.com>
>  > wrote:
>  > >
>  > > > Hey Jason,
>  > > >
>  > > > To get the environment passed in correctly, I use:
>  > > > RAILS_ENV=staging ./script/backgroundrb start
>  > > >
>  > > > And just to make sure, you're aren't actually calling your staging
>  > > > environment "stage" are you?  Or if you are, you have an environment
>  > > > intentionally named that, right?  Just had to ask :).
>  > > >
>  > > > stevie
>  > > >
>  > >
>  > > _______________________________________________
>  > > Backgroundrb-devel mailing list
>  > > Backgroundrb-devel at rubyforge.org
>  > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>  > >
>  >
>  >
>


More information about the Backgroundrb-devel mailing list