On Mon, Aug 28, 2006 at 01:20:29AM -0700, David Ranney wrote: > Jens, > > Thanks for your response. I see errors in either the importer (batch) > script or in the web app. The traces I happened to post previously > were both from the batch script. Here are the relevant lines from a > typical error found in the rails app's error log. > > -Dave > > ActionView::TemplateError (Lock Error occured at <except.c>:79 in xraise > Error occured in index.c:3089 - ir_is_latest > Error trying to commit the index. Commit lock already obtained
ok, it seems that the check to see if the current IndexReader is based on the latest version of the Ferret index wants to obtain a write lock and fails, since the batch indexing job already has locked it. This check is done by the Ferret::Index::Index class before every search. Maybe Dave could shed some light on how to handle these errors ? Imho Ferret should retry some more times to obtain a lock before failing that way. As a short term fix, one could catch the lock error in Ferret::Index::Index#ensure_reader_open and continue as if index_reader.latest? had returned true. That would prevent the search from failure due to a locked index. In the opposite direction, i.e. if latest? grabbed the lock and the indexing failed, a simple retry (calling record.save another time) could solve the problem, too. Jens -- webit! Gesellschaft für neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Krämer [EMAIL PROTECTED] Schnorrstraße 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66 _______________________________________________ Ferret-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/ferret-talk
