Ferret 0.11.0-rc1

rubyonrails-talk
1

Hey folks,

Sorry for cross posting like this but this is an important announcement for all Ferret users.

** Description **

Firstly for those who don't know, Ferret is a full-text search library which makes adding search to your application a breeze. It's much faster than MySQL full-text search as well most other search libraries out there. It allows you to do Boolean (+ruby + rails -jewelry) and phrase queries ("the quick brown fox") as well as some more unusual queries like fuzzy queries (misspelling~ matches mispeling or misspellng), wildcard queries (Aus?ral*), range queries (date:<=20050601) and a lot more. Ferret also now offers query result highlighting and excerpting.

** Announcement **

I've just released Ferret 0.11.0 which is the first release candidate for Ferret 1.0. This release has no new features to the API but it does fix some very major bugs. Ferret now uses lock-less commits which fixes a problem a lot of people where having with file not found exceptions. I've also fixed a number of bugs which were causing segfaults (hopefully all of them) so Ferret is now a lot more stable.

2

Hi David,

Just did an update to your 0.11.0 release and I am seeing some problems.

I cleared out my index as suggested and ran a query. However, my index is not rebuilding.

The error I am seeing is:

./script/…/config/…/config/…/vendor/plugins/acts_as_ferret/lib/class_methods.rb:195: [BUG] Bus Error ruby 1.8.5 (2006-12-25) [i686-darwin8.8.1]

Abort trap

I can see from the code that this is where it attempts to build the index.

Is this a bug in the new version or just me?

Keith

3

Hey Keith, I haven't tested on a Mac yet. I'll give it a go now.

4

Ok, I've just tried on my brothers Mac and it wouldn't even install until I made a simple fix. Are you sure it installed correctly without any errors? If it did, then there is another problem I need to be looking for. John Leach is also having troubles. Hopefully he can send me a repeatable test-case so we can sort that one out. It may even be the same problem that you are having. Anyway, we'll get this sorted ASAP.

Dave

5

Thanks David,

Yes it did install fine using the gem install routine.

If there is anything else I can test for you let me know.

Keith

6

Hi David,

Appologies for the BCC, wasn't sure if you were subscribed to rubyonrails-talk and I didn't want to cross-post the reply.

Before upgrading, I was running 0.11.0, but it appears as though the gem update I did just now picked up a newer version (0.11.3). Does this last one include all of the segfault+filenotfound fixes?

Before upgrading earlier today we hit a couple of bugs, all arising in the same scenario: one process is creating many ActiveRecord models which have acts_as_ferret, and so is updating the index, while the rails application itself (so another process) is doing lots of find_by_content(), the first of which take a very long time for some reason (no idea why the finds would themselves cause a re-indexing to happen, but they appear to).

The first time we ran our scenario, the process doing the creating barfed due to a wierd lock error:

/usr/local/ruby-1.8.5/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/commands/runner .rb:45: /usr/local/ruby-1.8.5/lib/ruby/gems/1.8/gems/ferret-0.11.0/lib/ferret/index. rb:666:in `initialize': Lock Error occured at <except.c>:117 in xpop_context (Ferret::Store::lock::LockError) Error occured in index.c:6044 - iw_open

Couldn't obtain write lock when opening IndexWriter

The second time it's the rails app itself that failed in the controller action doing the find_by_contents, and it failed with a different error: a file not found on a file that it was expecting to find in the index directory.

I haven't yet been able to reproduce these problems with 0.11.3 (they occured with 0.11.0), but I haven't tried very hard.

I guess my questions are:

1- with the latest version of ferret, 0.11.3, is concurrent access to the index from multiple processes supposed to work?

2- with the latest version of ferret, 0.11.3, if i add a bunch of stuff to the index, then do a find_by_contents which initially takes a long while (because it causes an indexing), then later add more to the index by creating acts_as_ferret models, should I expect the following find_by_contents to take a long time, just like the initial one? Right now it seems to be the case. I'm a little confused as to where/when the reindexing is supposed to happen, and why it seems index additions cause a reindexing by the following find_by_contents call.

-Bosko