Ooochie: A Ruby Developer’s Journal

I'm using the Workling Plugin with Starling on my project at Boost to run processes in the background. Recently, we deployed 2 projects on the same server, and rather than run 2 separate instances of Starling, we just let both apps talk to the same Starling instance. All was well with the world until I noticed that one of my apps was mysteriously creating records in the other app's database. Burn! It appeared that Starling didn't know which app the processes belonged to, so it was always running them on 1 app and never the other one. Eeek!

Thankfully, this was easily remedied by revisiting the options for my workling.yml file in the Workling README:

Workling copies a file called workling.yml into your applications config directory. 
The config file tells Workling on which port Starling is listening. 

Notice that the default production port is 15151. This means you'll need to start 
Starling with -p 15151 on production. 

You can also use this config file to pass configuration options to the memcache 
client which workling uses to connect to starling. use the key 'memcache_options' for this. 

You can also set sleep time for each Worker. See the key 'listeners' for this. 
Put in the modularized Class name as a key. 

    development:
      listens_on: localhost:22122
      sleep_time: 2
      reset_time: 30
      listeners:
        Util:
          sleep_time: 20
      memcache_options:
        namespace: myapp_development
        
    production:
      listens_on: localhost:22122, localhost:221223, localhost:221224
      sleep_time: 2
      reset_time: 30

See that key under memcache_options? Namespace to the rescue! If you set this in your workling.yml file, your Starling instance will never be confused again. Just a quick tip so you don't get burned like I did. Good luck!