search for: fsdirectory

Hi all, I''ve got a slight problem with using Ferret in unit tests. In order to create as little cross-contamination between test suites as possible, some of my tests are creating a fresh index per test case, and then calling Index#close and deleting the containing dir during the teardown. The problem comes when GC.start kicks in after the deleting the directory: IOError: IO Error

...m_index.optimize in_mem_index.close index = Ferret::Index::Index.new(:dir => ram_dir) index.persist(''path/to/index'', true) index.close I use a RAMDirectory when initially writing to the index because I am writing a lot to the index and I assume writing directly to a FSDirectory will be slower. Later, I am trying to load this index back into memory as a RAMDirectory. I am not actually sure how to do this, so I am guessing here: ram_dir = Ferret::Store::RAMDirectory.new index = Ferret::Index::Index.new(:dir => ram_dir, :create => true) index.add_indexes(Ferr...

...: class Article < ActiveRecord::Base acts_as_ferret :fields => [''title''] end 2. In the console, I try this: >> index = Article.ferret_index => #<Ferret::Index::Index:0x2b686dc76860 @writer=nil, @default_input_field=:id, @qp=nil, @dir=#<Ferret::Store::FSDirectory:0x2b686dc76748>, @mon_entering_queue=[], @default_field=["title"], @key=:id, @mon_count=0, @auto_flush=true, @open=true, @close_dir=true, @id_field=:id, @mon_owner=nil, @reader=nil, @searcher=nil, @options={:lock_retry_time=>2, :path=>"script/../config/../config/../index/dev...

Hi There, Is anyone using RAMDirectory as the data store with acts_as_ferret? I would love some pointers on how to configure acts_as_ferret to correctly use RAMDirectory (rather than FSDirectory). Thanks in advance. AC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ferret-talk/attachments/20060926/bd1230c5/attachment-0001.html

...#1 0x00000008013ca809 in abort () from /lib/libc.so.7 #2 0x0000000802cf7b39 in __cxa_pure_virtual () from /lib/libcxxrt.so.1 #3 0x00000008025159dc in lucene::store::BufferedIndexOutput::~BufferedIndexOutput () from /usr/local/lib/libclucene-core.so.1 #4 0x000000080251717a in lucene::store::FSDirectory::FSIndexOutput::FSIndexOutput () from /usr/local/lib/libclucene-core.so.1 #5 0x0000000802518983 in lucene::store::FSDirectory::createOutput () from /usr/local/lib/libclucene-core.so.1 #6 0x0000000802544c9d in lucene::index::CompoundFileWriter::close () from /usr/local/lib/libclucene-cor...

Hi! First, thanks a LOT for ferret. The API and documentation is great. I''m trying to integrate ferret into a RoR app (DamageControl) and have run into a problem with locks. DamageControl consists of two processes that start up and run in parallel. The first one is the webapp (which is just a plain RoR app). The second is a daemon process that runs in the background. The daemon process

...n involving multiple servers using the same index over nfs. The problem is that from what I have seen, ferret doesn''t support multiple processes writing to the same index. Using a DRb service is not an option since this would create a single point of failure. I tried using Ferret::Store::FSDirectory to create a write lock on the the index directory with code somewhat like this one: [...] dir = Ferret::Store::FSDirectory.new(INDEX_PATH) write_lock = dir.make_lock("lock") write_lock.obtain index << {:id => id, :type => ''create_test_type''}\ index.flush wr...

I''m trying to figure out if I should be setting close_dir to true or false when I access my index. It seems like this has something to do with the state that the index is left in after one process is finished using it, but it''s not clear exactly what this does. Can anybody explain further? Thanks, Carl

...Ferret. In my first program, which is using Lucene I search for ''influenza'' and get the following result plus a listing of all the filenames: Found 210 document(s) that matched query ''influenza Here is the Lucene code specific to searching: Directory fsDir = FSDirectory.getDirectory(indexDir, false); IndexSearcher is = new IndexSearcher(fsDir); QueryParser qp = new QueryParser("contents", new StandardAnalyzer()); Query query = qp.parse(q); Hits hits = is.search(query); For my second program, I use Ferret to search an index of the sa...

...#39;' => true irb(main):003:0> index = Ferret::Index::Index.new(:path => "/tmp/myindex") => #<Ferret::Index::Index:0xb7b23330 @writer=nil, @mon_entering_queue=[], @default_input_field=:id, @mon_count=0, @qp=nil, @default_field=:*, @options={:dir=>#<Ferret::Store::FSDirectory:0xb7b23308>, :path=>"/tmp/myindex", :lock_retry_time=>2, :analyzer=>#<Ferret::Analysis::StandardAnalyzer:0xb7b23268>, :default_field=>:*}, @mon_owner=nil, @auto_flush=false, @open=true, @dir=#<Ferret::Store::FSDirectory:0xb7b23308>, @id_field=:id, @searcher=nil,...

I''m using ferret (0.9.4) in rails, but outside of the "acts_as_ferret" plugin. Whenever I use a QueryFilter (even a very simple one), the server will crash after one, two, or three reloads of a page (same page, same query, same filter). It''s very non-deterministic and I can''t seem to reproduce it outside of my application environment (I can''t get it

..."URL 2: " + index[1]["url"] # passed, prints out correctly redirect_to(:action => ''new_index'') end Searching: if (@conditions != conditions) @records = Array.new sr = FerretConfig::SR sr.reader = Index::IndexReader.open(Store::FSDirectory.get_directory("/home/gregor/wisa/index")) qp = Ferret::QueryParser.new("id", { :analyzer => Ferret::Analysis::WhiteSpaceAnalyzer.new(), :wild_lower => false}) @records = sr.search(qp.parse(conditions)) end Search results are...

Hi, after a long indexing run I got the following error. I have 149 MB space left on the disk, the index is 311 MB large; could Ferret have tried to use more than that for the optimizing? Or would that have resulted in a different error message? /usr/local/ruby-1.8.5/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/commands/runner.rb:27:

I am using ferret right now, and it works great for all my regular text documents/information. My problem arises when I want to index/search all of our assets (mostly pdf files). Currently, there is no way to READ pdfs from Ruby. Because of this I have to resort to using Java to read the PDF''s and then Lucene to index them. My problem here is a couple things. One, to index a asset I have

Please excuse me if this has been answered before. Is there a "how-to" guide or a walkthrough on integrating Lucene with ROR via XMLRPC? I got Ferret to work but I am worried that it''s not going to be as scalable. I highly appreciate your assistance. Thanks Frank --------------------------------- Relax. Yahoo! Mail virus