Ferret::StateError while using acts_as_ferret

Ruby Apps Ferret
1

I’m fairly new to ferret / aaf and finding it much easier to use than
HyperEstraier (which I migrated from). However, I am getting a few
errors and I need to figure out if they’re problems with my usage of
ferret or a bug I should report. I’m currently running Ferret 0.10.11
with acts_as_ferret (latest via svn external) and 3 times today I’ve
seen the following error in production:

A Ferret::StateError occurred in directory#search:

State Error occurred at <except.c>:79 in xraise
Error occurred in index.c:2098 - stde_doc_num
Illegal state of TermDocEnum. You must call #next before you call
#doc_num

/usr/local/lib/ruby/gems/1.8/gems/ferret-0.10.11/lib/ferret/index.rb:370:in
`search.each’

The index in question is on a single model and contains about 330K
items. I’m not doing anything unusual as far as I know – just a call
to find_by_contents sorted by a timestamp (stored nontokenized). Can
anyone offer some advice on what I might be doing to cause this? I’m
also getting occasional segfaults (already submitted as a ticket on the
trac) but they don’t appear to be tied to this error.

Jim

2

On 10/13/06, Jim K. [email protected] wrote:

Error occurred in index.c:2098 - stde_doc_num
to find_by_contents sorted by a timestamp (stored nontokenized). Can
anyone offer some advice on what I might be doing to cause this? I’m
also getting occasional segfaults (already submitted as a ticket on the
trac) but they don’t appear to be tied to this error.

Jim

Hi Jim,
I’m not sure what might be causing this error. Did you reindex when
you upgraded to 0.10.11? That may help. If it doesn’t, try going back
to version 0.10.9. This error may have been introduced in the
performance enhancements I added in version 0.10.10.

Let me know how you go.

Cheers,
Dave

3

David B. wrote:

On 10/13/06, Jim K. [email protected] wrote:

Error occurred in index.c:2098 - stde_doc_num
to find_by_contents sorted by a timestamp (stored nontokenized). Can
anyone offer some advice on what I might be doing to cause this? I’m
also getting occasional segfaults (already submitted as a ticket on the
trac) but they don’t appear to be tied to this error.

Jim

Hi Jim,
I’m not sure what might be causing this error. Did you reindex when
you upgraded to 0.10.11? That may help. If it doesn’t, try going back
to version 0.10.9. This error may have been introduced in the
performance enhancements I added in version 0.10.10.

Let me know how you go.
I tried reindexing with 0.10.11 but this didn’t seem to help matters
(and it REALLY barfed while the reindex was going on). I downgraded to
0.10.9 and reindexed this morning; since the reindex finished, I haven’t
had a single segfault or StateError (previously I had plenty of both).
Hooray!

Jim

4

Jim K. wrote:

David B. wrote:

On 10/13/06, Jim K. [email protected] wrote:

Error occurred in index.c:2098 - stde_doc_num
to find_by_contents sorted by a timestamp (stored nontokenized). Can
anyone offer some advice on what I might be doing to cause this? I’m
also getting occasional segfaults (already submitted as a ticket on the
trac) but they don’t appear to be tied to this error.

Jim

Hi Jim,
I’m not sure what might be causing this error. Did you reindex when
you upgraded to 0.10.11? That may help. If it doesn’t, try going back
to version 0.10.9. This error may have been introduced in the
performance enhancements I added in version 0.10.10.

Let me know how you go.
I tried reindexing with 0.10.11 but this didn’t seem to help matters
(and it REALLY barfed while the reindex was going on). I downgraded to
0.10.9 and reindexed this morning; since the reindex finished, I haven’t
had a single segfault or StateError (previously I had plenty of both).
Alright, I was going to add this to the open trac ticket I have
regarding segfaults but akismet appears to be in a bad mood today. My
earlier observations were based on a static index, which is great and
all, but I do need to update it throughout the day. I restarted the
update process and within an hour I encountered 2 segfaults. I’m not
sure where to go from here.

Jim