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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > 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 > > > [email protected] > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > > > > _______________________________________________ Backgroundrb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/backgroundrb-devel
