[Backgroundrb-devel] rails_env configuration conflict...

[Jacob Robbins]

it seems that the way backgroundrb is intended to be used is to keep 
backgroundrb.yml out of subversion via svnignore properties and then 
maintain separate copies of it on each server.

it would be nice if more than one method of configuration was fully 
supported, perhaps you could document the specific cases that you have 
found to misbehave and add them to the trac. Someone else on the list 
mentioned that the -r commandline option to script/backgroundrb start is 
also inconsistent enough to prevent it's use in production.

-Jacob

Brett Walker wrote:
> I've found a conflict in the way the configuration file is handled, in
> particular effecting the setting of the ENV['RAILS_ENV'] value.
> 
> When I attempted to run a worker in production, it would run fine the
> first time - the second time would fail because it was trying to
> access the development database.
> 
> I had created a 'backgroundrb_prodcution.yml' file that I was passing
> in when starting up backgroundrb.  Setting the ENV['RAILS_ENV'] to
> production didn't help.
> 
> In BackgrounDRb::Config, it set the ENV['RAILS_ENV'] to the value
> :rails_env value in the config file, and defaults to development.
> 
> What seems to be happening is that when the Rails environment is
> getting loaded for a new worker (I guess after the first time), then
> BackgrounDRb::Config class gets executed.  The config file doesn't
> seem to be specified - so it defaults to reading the default
> backgroundrb.yml file, which sets the :rails_env to development.
> 
> If I remove the :rails_env line from the backgroundrb.yml file, and
> set RAILS_ENV when I start backgroundrb, it works.
> 
> Not sure how to fix the problem in general.
> 
> Cheers,
> Brett
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel