Brett Walker
2007-Jan-29 03:52 UTC
[Backgroundrb-devel] rails_env configuration conflict...
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
Jacob Robbins
2007-Jan-29 16:51 UTC
[Backgroundrb-devel] rails_env configuration conflict...
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