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 with aaf/ferret. 1) 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. 2) 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. 3) 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. 4) 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 overall. Thoughts? -- Posted via http://www.ruby-forum.com/. _______________________________________________ Ferret-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/ferret-talk
