Jens Krämer

acts_as_ferret 0.4.0 RIE

 |  ferret, rails

It’s been some time since the last release, but finally here it is - the DRb powered Remote Indexing Edition of acts_as_ferret.

As you already might have guessed, among several bug fixes the major new feature is the built in DRb server that allows any number of process or even physical machines to access a single central Ferret index instance - saving you memory and the possible locking hassles.

Get It

To install this release, use script/plugin install svn://projects.jkraemer.net/acts_as_ferret/tags/stable/acts_as_ferret

A RubyGem is available, too, I guess you know how to handle that…

About the DRb indexing server

In production environments most often multiple processes are responsible for serving client requests. Sometimes these processes are even spread across several physical machines.

Just like the database, the Ferret index of an application is a unique resource that has to be shared among all servers. To achieve this, acts_as_ferret now comes with a built in DRb server that acts as the central hub for all indexing and searching in your application.

The DRb server has been in trunk for a month or so now. Since then I have received positive feedback from several people, including Ryan King from Technorati, who says they’re using it in production mode for an experimental microformats search app over at the Technorati kitchen.

Use it in your Rails app

If you installed acts_as_ferret using script/plugin install, you’ll find start/stop scripts for the server in the script/ subdirectory of your Rails app, and the ferret_server.yml configuration file in config/.

The config file is similar to database.yml, for each environment you can specify the hostname and port for the server, and the location of the pid file (relative to RAILS_ROOT).

To only use the DRb server in production environments, simply remove the test and development sections from the config. Now tell acts_as_ferret to use the DRb server, if one is configured for the current environment:

acts_as_ferret :fields => [ ... ], :remote => true

Instead of removing sections from the config file, you could also specify the :remote parameter depending on the current environment.

Don’t forget to start the server on the machine that you configured in ferret_server.yml: RAILS_ENV=production script/ferret_start

The server will deamonize itself and write a pid file to log/ferret.pid. It’s log file is log/ferret_server.log and it’s standard output and error get redirected to log/ferret_server.out. If anything goes wrong, you should have a look there to see what the problem is.

As always I’m eager to hear your feedback, so don’t hesitate to comment or drop me an email. Or even better, post to the ferret-talk mailing list (ferret-talk@rubyforge.org or at ruby-forum.com).

Comments

Levent

Any idea why I'm getting:


/usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/commands/runner.rb:27: (eval):1: compile error (SyntaxError)
(eval):1: syntax error, unexpected '.'
./script/ferret_start
^ from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `eval'
from /usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/commands/runner.rb:27
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require'
from script/runner:3


...when I do ./script/ferret_start

Is it incompatibility with rails 1.1.6?

John

I have the same problem.

Jens

running

script/runner 'load "script/ferret_start"'

instead should help.