I blogged about some of the problems with aaf in production
(http://www.jroller.com/BrightCandle) yesterday but inspired by the
poitive response I thought I would share the perceived problems and
discuss some of the potential solutions to help newcomers and make aaf
work as if by magic just like Rails does.
All of these problems boil down to one simple problem, running acts as
ferret in a production environment simply is not consistent with the
rails behaviour. Rails is single threaded system, resulting in multiple
processes on a single server. Even the basic deployment scenario of
Mongrel + Pen/Pound/Balance + Rails you have multiple processes. AAF in
this case breaks without Drb, I don’t think that how you develop should
be different to how its run in production. Rails doesn’t need a thing
changing to work and that is the root cause of the production problem
Each model needs remote => true adding to it for remoting to work.
This is a breach of the DRY principle.
Solution: Get rid of this requirement, if the config is there then use
it, if its not then don’t.
aaf needs to be installed as a plugin to get the start/stop scripts.
Solution: Add startFerret, stopFerret Drb scripts to the gem so that
even if it is not installed as a plugin the gem is still useable.
Drb server is a central point of failure.
Solution 1: Lucence locks the file while it works which effectively
allows many threads to write but it serialises them. This should be the
case with aaf as well, at least then basic parrallism will work without
having to setup up Drb or any other config settings. Sure you could
get fancy with partial locking schemes but right now what I think I care
about is it at least work. Drb should be the next performance step from
Solution 1, improving performance at the cost of reliability.
Solution 2: Support clustered behaviour of the Drb servers, write to all
read from one just like a database.
Solution 3: Allow the index to be stored in the database and use
transactions to manage the updates (Just as compass does to lucene)
Solution 4: You could write a multicast clustered behaviour system to
make only one of the rails servers write to the file while all the
others read from it. Probably more complex a solution than is needed.
- AAF fails unexpectedly if you just use it without Drb.
Solution: Produce a warning if more than one thread/process seems to be
updating the file at any one time. Although bare in mind Solution 1 for
problem (3) solves this in a different way and is a better solution