similar to: DRb server & aaf gem

I''ve installed the ferret gem. I installed AAF as a plugin into my vendor/plugins directory of my project. In development environment my searches work just fine, without any problems. For production I configured the ferret_server.yml file with correct information about the machine my DRb server is running on. I start the ferret server with the following command: ruby script/runner

When trying to start ferret with capistrano, I keep getting this: $ cap services:ferret:stop domain [redken.digitalpulp.com] : user [john] : * executing `services:ferret:stop'' * executing "cd /srv/rails/redken/current; script/ferret_server -e production stop" servers: ["redken.digitalpulp.com"] Password: [redken.digitalpulp.com] executing command ***

We all know that using ferret/aaf without the drb server is not thread-safe-- but why not? Would it be so hard to sacrifice performance by using a simple locking system? Very often I run into a situation where I want to quickly stage a project, and I want to use a few mongrels but don''t want to configure every last piece of the system, including the drb server. It would be nice

Jesse Grosjean wrote: > I''m trying to write a solaris SMF file to launch the ferret drb server. Hmm, I think I''ve hit a similar problem. I''ve just upgraded to the latest ferret trunk from an old aaf stable where the script/ferret_start and script/ferret_stop scripts were still in use. now if I call the old script... RAILS_ENV=production script/ferret_start

I am using AAF trunk, and I want a way to rebuild an index on a production site with little or no interruption to service. The Drb Server documentation* states that when an index is rebuilt, it is done in a separate location and then swapped into place when finished, and so to do a complete rebuild on a live site, one must take into consideration objects which have been created or

Hi all, We''re attempting to use Ferret with the DRb server at the moment, and it doesn''t work, at all... = Executive Summary The DRb server process keeps on calling the remote index to the DRb server process... Which means DRb is calling itself, and itself, and itself, until Ruby kills the Thread with a SystemStackLevel error. = The excruciating details... # Mongrel is

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

This is important and may be affecting you if you use :select to minimize the columns you need on big queries. If you use :select to define which columns you need and you have not included all the columns you defined in the :acts_as_ferret field definitions you''ll clear the content of those fields on the ferret index. And that may corrupt your index. So, if you have in your model:

Hi folks, I have several models that index well in Drb mode. However, I have one scenario where it works in normal mode, but not in Drb mode. model A field :one end model B belongs_to :a field :two delegate :one, :to => :a acts_as_ferret :fields => { :one => {}, :two => {} }, :remote => true end If I leave off the :remote parameter, it works. Or, if I don''t

is the list of indexed words readily available via aaf or directly from ferret? -- Posted via http://www.ruby-forum.com/.

Hi, I have configured my model as follows: class Product < ActiveRecord::Base acts_as_ferret :fields => [:description,:label_description,:label_free,:product_id_supplier,:description_supplier,:supplier_description] belongs_to :supplier def supplier_description return "#{self.supplier.description}" end In the development log I can see the supplier_description

Hi, we still have the problem in that the Ferret Drb server dies on us sometimes. Looking through ferret_server.out and we come accross this: deadlock 0xb7261cb0: sleep:F(1012) - /usr/lib/ruby/1.8/drb/drb.rb:566 deadlock 0xb71d8654: sleep:F(409) - /usr/lib/ruby/1.8/drb/drb.rb:566 deadlock 0xb723f3e0: sleep:F(7) - /usr/lib/ruby/1.8/drb/drb.rb:566 deadlock 0xb72607c0: sleep:F(11) -

Anyone ever run into this error message when creating a new FieldInfos? Ferret::Index::FieldInfos.new(:store=>:no) NoMethodError: undefined method `exists?'' for {:store=>:no}:Hash -- Posted via http://www.ruby-forum.com/.

The documentation* states that when using a single index for multiple models, the default_field list should be set to the same thing for all models. However, in my application, all my models have very different fields and this is not possible. I still want the results returned sorted by term frequency across all indexed content in each model. What is the purpose of default_field? Under

The documentation states: "single_index: set this to true to let this class use a Ferret index that is shared by all classes having :single_index set to true. :store_class_name is set to true implicitly, as well as index_dir, so don?t bother setting these when using this option. the shared index will be located in index/<RAILS_ENV>/shared ." [1] If I''m reading

My project is currently using AAF 0.4.3. Trunk has some compelling features, but my project is going live on Monday and I am apprehensive about switching. Is anyone using trunk in a relatively high-volume context? (A low and vague standard for evaluating production suitability, I know, but better than nothing). Thanks, John

I need a way to kill the ferret_server drb process programatically, so I can start/stop it as part of the capistrano deployment process. This should be as simple as adding some sort of stop method to ActsAsFerret::Remote::Server. I was just messing around and was able to do it by modifying method_missing to look for the :stop method and then calling DRb.thread.exit -- this is not good enough for

I had sort-by-date working almost perfectly with my app. It was behaving as expected for most data, but had a few hiccups with certain data. I investigated and discovered that the correct data was storing this in my ferret index: "1999-10-18 00:00:00" and the incorrect data was storing this: "Mon Oct 18 00:00:00 EDT 1999" (oops...) So I of course had to fix the

I am experience situations where accessing the index results in a complete re-indexing of the model. I have not been able to detect a pattern. Under what circumstances does Ferret (or AAF) decide that it needs to rebuild the index? I''ll be happy to look at the code relevant to this if someone could direct me to it. Thanks, John

Hi all, I cannot make aaf (rev. 220) use my custom analyzer, despite following the indications @ http://projects.jkraemer.net/acts_as_ferret/wiki/AdvancedUsage To pinpoint the problem, I created a model + a simple analyzer with 2 stop words : "fax" and "gsm". test 1 : model.rebuild_index + model.find_by_contents("fax") # fax is a stop word. => I get a