similar to: ferret success stories?

> From: Jens Kraemer <jk at jkraemer.net> > Subject: Re: [Ferret-talk] Performance before and after optimization > On Sat, Nov 03, 2007 at 08:49:17PM +0800, Alex Neth wrote: > [..] >> 2) Can I keep a second index so that it doesn''t get locked during >> optimization and then switch to the optimized index? Perhaps the >> index >> is not really

Thanks Stuart. I thought I had read somewhere that rebuild_index built the index in a different location and then swapped it, but after looking at the code (in local_index.rb) this doesn''t appear to be the case. That might explain why the ferret server crashes sometimes when a search takes place during a reindex. I wouldn''t be doing exactly the same thing as this but

Thanks for the response Jens. Indeed I am sorting by something other than relevancy, so that would explain it. Optimized, it''s extremely fast and handles a good load, but new records kill it until I optimize. I haven''t tried :merge_factor as I wasn''t aware of it. I''m not sure it will help given the above. Regarding the re-index locking code,

Hi ferreteers, I came across a segfault in the query parser. It had already been reported[1] and fixed[2], but it can lead to a denial of service. If you use Ferret anywhere that you allow users to execute queries, those users can crash your Ruby process with a specially crafted query. I''m sure you''re all using Monit or something for your Rails or drb processes, so

I''ve been running some multithreaded tests on Ferret. Using a single Ferret::Index::Index inside a DRb server, it definitely behaves for me as if all readers are locked out of the index when writing is going on in that index, not just optimization -- at least when segment merging happens, which is when the writes take the longest and you can therefore least afford to lock out all reads.

I''m trying to use the Ferret DRB server to avoid concurrency issues when using multiple mongrels. I can successfully add and edit data on my index via the DRB server, however, when I search the index, I get the following error: DRb::DRbConnError (DRb::DRbServerNotFound): /usr/lib/ruby/1.8/drb/drb.rb:1647:in `current_server'' /usr/lib/ruby/1.8/drb/drb.rb:1709:in

I am new to ferret and am just reading about it in the O''reilly shortcuts as well as other web resources. My app is a Rails app and so I am looking into acts_as_ferret as well. There are some questions for which I couldn''t find answers in the material I have read so far so I''d appreciate any help on these from the list. A bit of a background. My app will have 10,000 -

Hi, I have my Model as follows: class Mutation < ActiveRecord::Base acts_as_ferret ({:fields => {:description=>{}, :product_id=>{:index => :untokenized}, :product_description=>{}, :product_label_description=>{}, :product_label_free=>{}, :product_product_id_supplier=>{}, :product_description_supplier=>{}, :supplier_description=>{}, :pub_date_sort

Hi all, I upgraded from Ferret 0.11.3 to Ferret 0.11.4 because I was getting intermittent segfaults that seemed to be due to a bug which was fixed (changeset 749). Unfortunately, 0.11.4 + acts_as_ferret seems to be a bad combination. I''m getting the some "fs_store/File Not Found Error occured at <except.c>:117" which was reported in the "Constant 0.11.4

Hi Everyone, I was wondering if folks here have had experience scaling Ferret beyond a single server? Currently, we are running Ferret in the same physical server as its Rails front end (via acts_as_ferret), but it is evident that we need a more scalable solution already. How would you split up the tasks (via dRB perhaps?) between two or three servers? Shared disk, replicated Ferret index (?),

I have spent days trying to figure out how to get UTF-8 working with my site. Here''s my environment: Linux version 2.6.16.29-xen_3.0.3.0 Ruby 1.8.4 (2005-12-24 [i386-linux] Rails 1.2.3 mongrel (1.0.1) mongrel_cluster (1.0.2, 0.2.1) ferret (0.11.4) acts_as_ferret stable plugin Ferret DRB server When I don''t use an analyzer with my acts_as_ferret declaration, everything works

Hi list, We just built our own ferret drb server (mostly because we don''t do an indexing from within rails). The ferret drb server only handles index inserts and some deletes. Usually we make batch inserts were we retrieve a couple of hundred or thousands of documents from a database and then inserts them inte ferret one by one. We call flush every 50th file. We are very impressed

If I disable ferret in my environment file and then run a cron job every hour to index the records that have been added/changed, do I enable Ferret just in the script that does the hourly indexing? Or do I somehow need to tell the process that runs the Ferret DRB server that it should start writing to the index again? Thanks in advance. Erik

Greetings, I''ve been using ferret with great results now for a while, but in the last week, I''ve been running into some issues. I will occasionally see this message: Exception Message: Lock Error occured at <except.c>:103 in xpop_context Error occured in index.c:5368 - iw_open Couldn''t obtain write lock when opening IndexWriter Which is accompanied by

I am running ferret (0.11.4) and acts_as_ferret (stable from svn) in a rails 1.2.3 app in production using the DRb server. I recently upgraded my configuration and the method with which I start and stop the server no longer works: Here is the command I would like to use (and have used in the past) to start the aaf server: $ /Library/WebServer/rails/ccdb/current/script/runner -e production

Using the Drb allows me to synchronize writes to the index in a multi mongrel environment. I was under the impression that the remote index would not block if two mongrels were searching the index. Is that the case? This line in ferret_server.rb makes me think otherwise: # Calls are not queued atm, so this will block until the call returned. # def method_missing(name,

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

We''ve been running into problems with ferret indexing lately. The problem is intermittent and some times it persists. Just got this after wiping the index and redeploying: NoMethodError (undefined method `add'' for Solution:Class): (druby://10.1.65.87:9009) /data/releases/20071111152414/vendor/rails/activerecord/lib/active_record/base.rb:1238:in `method_missing''

The problem with getting DRb to luanch on reboot is the same problem causing some people to ahve trouble getting mongrel clustersw to come back up on reboot. The problem is the PATH. ON many new RH distributions running SELinux, /usr/local/bin is not added to the PATH until reboot is complete. Therefore, those of having installed ruby in /usr/local/bin run in to issues. SO, hoping to save

Greetings, I''m certainly :-) too thick, but after reading Ferret and AAF''s documentation I''m still wondering if I really need a DRb server in production. At the moment, the planned structure for production mode is a single server running the app with Apache and fastcgi; as far as I know, Ferret is multithread-safe, isn''t it? So, is a DRb server required to