Ferret 0.11.0-rc1

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.

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

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

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

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

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