[Backgroundrb-devel] rails_env configuration conflict...
jrobbins at cmj.com
Mon Jan 29 11:51:30 EST 2007
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.
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.
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
More information about the Backgroundrb-devel