In the process of integrating BackgrounDRb into my company''s CRM application for our web site, I have run against two roadblocks in configuration that required my actually modifying the BackgrounDRb source code to work around: 1. The MasterProxy class overrides the RAILS_ENV settings with the settings in the backgroundrb.yml, or sets the environment to "development" if not set. This makes it impossible to allow the server to run in multiple configuration environments (e.g. staging and production, for example). In my opinion, it would be best to have MasterProxy rely solely on the current setting of RAILS_ENV, and never override it under any circumstances. 2. DebugMaster supports only logging options: log to files with hard-coded names, or log to stdout. In our clustered production environment, we use SyslogLogger to send all logging messages to a remote server, in order to maintain logs for all our servers in one place. There appears to be no way to do this in BackgrounDRb without modifying the behavior of DebugMaster. Apart from these two issues, this is a great tool for asynchronous processing. Thanks! George Feil | Senior Software Engineer www.realgirlsmedia.com www.divinecaroline.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080206/845e3fcc/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3238 bytes Desc: image001.jpg Url : http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080206/845e3fcc/attachment.jpe
Hi George, On Wed, 2008-02-06 at 16:39 -0800, George Feil wrote:> In the process of integrating BackgrounDRb into my company?s CRM > application for our web site, I have run against two roadblocks in > configuration that required my actually modifying the BackgrounDRb > source code to work around: > > > > 1. The MasterProxy class overrides the RAILS_ENV settings with > the settings in the backgroundrb.yml, or sets the environment > to ?development? if not set. This makes it impossible to allow > the server to run in multiple configuration environments (e.g. > staging and production, for example). In my opinion, it would > be best to have MasterProxy rely solely on the current setting > of RAILS_ENV, and never override it under any circumstances. > 2. DebugMaster supports only logging options: log to files with > hard-coded names, or log to stdout. In our clustered > production environment, we use SyslogLogger to send all > logging messages to a remote server, in order to maintain logs > for all our servers in one place. There appears to be no way > to do this in BackgrounDRb without modifying the behavior of > DebugMaster. > > > > Apart from these two issues, this is a great tool for asynchronous > processing. Thanks! >It will be interesting to see your patches.
Hah! I''ve been hacking around this for hours today.
My old solution was something like this in config/backgroundrb.yml:
============<%
ports = {
''development'' => 2000,
''production'' => 2001,
''demo'' => 2002,
''sandbox'' => 2003
}
%>
---
:backgroundrb:
:port: <%= ports[ENV[''RAILS_ENV'']] %>
:environment: <%= ENV[''RAILS_ENV''] %>
:ip: 127.0.0.1
============
But that failed when I started starting bdrb with capistrano because I
couldn''t set RAILS_ENV (have to run bdrb sudo -u nobody). So my
solution was
to create config files for each environment that are symlinked into the new
cap-created directory.
I''d agree that setting RAILS_ENV is unoptimal. It does really
unexpected
things if you''re relying on RAILS_ENV after starting bdrb.
On 2/6/08, George Feil <gfeil at realgirlsmedia.com>
wrote:>
> In the process of integrating BackgrounDRb into my company''s CRM
> application for our web site, I have run against two roadblocks in
> configuration that required my actually modifying the BackgrounDRb source
> code to work around:
>
>
>
> 1. The MasterProxy class overrides the RAILS_ENV settings with the
> settings in the backgroundrb.yml, or sets the environment to
> "development" if not set. This makes it impossible to allow
the server to
> run in multiple configuration environments (e.g. staging and
> production, for example). In my opinion, it would be best to have
> MasterProxy rely solely on the current setting of RAILS_ENV, and never
> override it under any circumstances.
> 2. DebugMaster supports only logging options: log to files with
> hard-coded names, or log to stdout. In our clustered production
environment,
> we use SyslogLogger to send all logging messages to a remote server, in
> order to maintain logs for all our servers in one place. There appears
to be
> no way to do this in BackgrounDRb without modifying the behavior of
> DebugMaster.
>
>
>
> Apart from these two issues, this is a great tool for asynchronous
> processing. Thanks!
>
>
>
> George Feil | Senior Software Engineer
>
> www.realgirlsmedia.com
>
> www.divinecaroline.com
>
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080206/5011aaab/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3238 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080206/5011aaab/attachment.jpe