Wednesday, March 14, 2007

Pitfalls of acts_as_ferret, with DrbServer to the rescue

I don't know how general this case is, but I've found that if you want to use acts_as_ferret in your production Rails app, you need to run your Ferret server as a separate DrbServer process.

Background

acts_as_ferret gives you a powerful search capability, and it's much easier to implement than MySQL full text querying.

Numerous tutorials (here and here) describe how to do this. In development mode, it's as simple as adding something like this to your model:

acts_as_ferret :fields => [ :city, :state ]

and this to your controller:

@users = User.find_by_contents(params[:keywords])

Problem

I started getting all kinds of corrupted index errors when I put this into production, because acts_as_ferret can't handle multiple separate processes access the index at once. This caused a lot of scrambling as I was starting to get a lot of traffic.

Solution

Fortunately I discovered that acts_as_ferret comes with its own built-in DrbServer. As soon as I set that up, everything worked great.

The developer does a great job explaining what to do. You add :remote => true to your acts_as_ferret declaration, setup a ferret_server.yaml config file, then run:

RAILS_ENV=production script/runner vendor/plugins/acts_as_ferret/script/ferret_server

...and you're golden.

UPDATE: To make the acts_as_ferret unit tests run correctly, add the following line to your test/environment.rb file:

AAF_REMOTE = true

Saturday, March 10, 2007

First web app launch

I launched my first web application today! It's a small site to help people find potential company co-founders:

FounderFinder.com


It's getting pretty good reviews from the site I originally got the idea from.