Hi,
I use ferret 0.10.4 whith shared index over NFS directory.
There are 2 applications servers. The web server is Mongrel 0.3.13.3
and mongrel_cluster 0.2.0. There are 20 Mongrel processes on each
server.
Each time my application update a model, Mongrel process
stops running with this errro in its log:
/usr/lib/ruby/gems/1.8/gems/ferret-0.10.4/lib/ferret/index.rb:663:
[BUG] Segmentation fault
Theses servers are serving a lot of requests. Is it good to have
shared NFS index ? Is there a lock problem ?
This is very urgent. 10000 thanks for any help.
Regards
Seb
Hi!
On Sat, Sep 16, 2006 at 12:53:48PM +0200, Sebastien H. wrote:
/usr/lib/ruby/gems/1.8/gems/ferret-0.10.4/lib/ferret/index.rb:663:
[BUG] Segmentation fault
Theses servers are serving a lot of requests. Is it good to have
shared NFS index ? Is there a lock problem ?
Possible that there are locking problems. We had this question come up
some days ago on the list, hope Dave can shed some light on this.
I’m working on remote indexing capabilities for acts_as_ferret right
now. Atm I have a little drb server that does the indexing/searching,
and an experimental branch of acts_as_ferret that can talk to this
server.
So you’d only have one index and both machines talking to this. Drop me
line if you’re interested in a solution like this.
Jens
–
webit! Gesellschaft für neue Medien mbH www.webit.de
Dipl.-Wirtschaftsingenieur Jens Krämer [email protected]
Schnorrstraße 76 Tel +49 351 46766 0
D-01069 Dresden Fax +49 351 46766 66
Jens K. wrote:
Hi!
On Sat, Sep 16, 2006 at 12:53:48PM +0200, Sebastien H. wrote:
/usr/lib/ruby/gems/1.8/gems/ferret-0.10.4/lib/ferret/index.rb:663:
[BUG] Segmentation fault
Theses servers are serving a lot of requests. Is it good to have
shared NFS index ? Is there a lock problem ?
Possible that there are locking problems. We had this question come up
some days ago on the list, hope Dave can shed some light on this.
I’m working on remote indexing capabilities for acts_as_ferret right
now. Atm I have a little drb server that does the indexing/searching,
and an experimental branch of acts_as_ferret that can talk to this
server.
So you’d only have one index and both machines talking to this. Drop me
line if you’re interested in a solution like this.
An alternative and IMO better solution is to disable indexing in the
Rails app and use an external process that periodically reindexes
changed (updated_at > last_update) records. This has the additional
advantage that the index update can’t block or crash the Rails app
servers.
On Mon, Sep 18, 2006 at 09:09:07AM +0200, Andreas S. wrote:
some days ago on the list, hope Dave can shed some light on this.
changed (updated_at > last_update) records. This has the additional
advantage that the index update can’t block or crash the Rails app
servers.
Right, depending the exact application this may be a better solution.
Plus
you’d get better performance with batch-indexing new/updated records.
but, if an index update crashes your rails server, it’ll most likely
crash your background indexer, too - you’re just moving the problem away
from the surface. Of course, having a stale index but the rest of the
app working is better than having the whole app crashed 
In addition, the index won’t be guaranteed to be always up to date, and
deleted records will have to be handled, maybe by flagging them as
deleted instead of really deleting them.
Jens
–
webit! Gesellschaft für neue Medien mbH www.webit.de
Dipl.-Wirtschaftsingenieur Jens Krämer [email protected]
Schnorrstraße 76 Tel +49 351 46766 0
D-01069 Dresden Fax +49 351 46766 66
FYI, it is a long time known issue between Java Lucene and NFS
mounted file systems. There is actually quite a bit of active work
going on in this space in the Java Lucene community.
Erik