acts_as_ferret 0.4.0 RIE
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
/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
Jens
script/runner 'load "script/ferret_start"'
instead should help.