[Backgroundrb-devel] Very strange after_save problem. Please help.

Ezra Zygmuntowicz ezmobius at gmail.com
Tue Jul 18 11:40:34 EDT 2006

On Jul 18, 2006, at 6:54 AM, Christian Romney wrote:

> Hi all,
> I'm looking for a little deployment guidance. I have a webfarm with  
> two app servers running rails that need to make use of BackgrounDRb.
> I presume I should have a single machine running backgroundrb,  
> since otherwise we would run the chance of a client switching  
> servers and polling for a non-existent job.
> Assuming I need to change the backgroundrb.yml file on the two app  
> servers to point to an instance running on some third machine, I'm  
> a little lost on what each config should look like.
> (The config on the app servers vs. the config on the drb server).  
> Any guidance is much appreciated. Alternatively if there's an  
> effective way to "cluster" backgroundrb instances and maintain a  
> global, shared keyspace (thinking of Mogilefs, for instance) I'd  
> welcome suggestions as well.
> Thanks for releasing such a great tool!
> Christian Romney

Hey Christian-

	Yeah you will want to run the drb server one either one of the two  
app servers or a third box depending on your setup. THe way things  
work is that backgroundrb is tied to your rails app so if you run it  
on a third box you will still need to check out a copy of your app  
onto that third box. You just wont run the rails app part of it and  
only the drb server. In the config file you will need to set your IP  
addresses and your acl lists correctly.

Here is a config file. You will want to change probably the port  
number, the IP address and the acl list. Lets say you will run the  
drb server on and your two app servers are &

port: "22222"
timer_sleep: 60
load_rails: true
environment: development
database_yml: config/database.yml
   deny: all
   allow: localhost
   order: deny,allow

You will need to make sure that the backgroundrb.yml config file is  
the same in all three places so they all point to the same drb server.

As far as clustered drb servers, that is something I do plan on  
tackling but probably not for another month or so. I plan on setting  
up a distributed worker pool using Rinda and tuplespace to have a  
pool of backgroundrb processes available at any one time.


More information about the Backgroundrb-devel mailing list