Greetings, I've been using ferret with great results now for a while, but in the last week, I've been running into some issues. I will occasionally see this message: Exception Message: Lock Error occured at <except.c>:103 in xpop_context Error occured in index.c:5368 - iw_open Couldn't obtain write lock when opening IndexWriter Which is accompanied by mongrel segfaulting with this message in the logs: /usr/local/lib/ruby/gems/1.8/gems/ferret-0.10.13/lib/ferret/index.rb:284: [BUG] Segmentation fault This is only happening for one particular project within the app I maintain, each project has it's own indices. I've tried deleting and rebuilding the index, but it didn't seem to fix the problem. I read that newer versions of ferret have resolved some issues with users who have locking problems. Would that be a good strategy here as well? Thanks for your help, dan
on 2007-04-19 19:26
on 2007-04-20 15:45
Hi Dan, I had these problems too with 0.10.* and they've gone in 0.11.* (not sure which exact version though, latest is 0.11.4 and no segfaults there for me). You still need to be careful when having multiple processes writing to the same Ferret database though (which I'm assuming you're doing here to get this error). It won't segfault any more but you could still get write lock errors. The general advice seems to be to use DRb to provide a ferret object for multiple processes (aaf has this in trunk now I believe). John. On Thu, 2007-04-19 at 10:12 -0700, dph wrote: > > /usr/local/lib/ruby/gems/1.8/gems/ferret-0.10.13/lib/ferret/index.rb:284: [BUG] Segmentation fault > -- http://johnleach.co.uk
on 2007-04-20 17:09
John, Thanks very much for your help! I'm going to write a DRb process to build the indexes for search today. When you upgraded to 0.11, did you have to destroy and recreate all of your indexes? dan
on 2007-04-20 20:08
0.11 does change the on-disk format iirc, so you'll need to rebuild. Let me know how you get on with the DRb process, as I've seen some recycled object and invalid reference errors with my code under load. John. On Fri, 2007-04-20 at 07:53 -0700, dph wrote: > John, > > Thanks very much for your help! I'm going to write a DRb process to > build the indexes for search today. > > When you upgraded to 0.11, did you have to destroy and recreate all > of your indexes? > > dan > -- http://johnleach.co.uk
on 2007-04-24 01:58
Hi there, I am getting this error very often on our website now that it is experiencing heavey traffic (www.mintd.com). I'd like to address this problem. Can you please explain what is meant by "DRb" to avoid these write lock errors? Many Thanks, Lachlan John Leach wrote: > The general advice seems to be to use DRb to provide > a ferret object for multiple processes (aaf has this in trunk now I > believe).
on 2007-04-24 10:53
On Tue, Apr 24, 2007 at 01:58:35AM +0200, Lachlan Laycock wrote: > Hi there, > > I am getting this error very often on our website now that it is > experiencing heavey traffic (www.mintd.com). I'd like to address this > problem. Can you please explain what is meant by "DRb" to avoid these > write lock errors? DRb is a way to for Ruby programs to communicate between processes. In the context of Ferret it means to set up one server process that does all the indexing (and searching). The 'real' application processes (e.g. Mongrel instances) only access the index through this DRb server. This usually eliminates all the locking problems that might arise since now always only one process is accessing the index. If you use acts_as_ferret, you can use the built-in DRb server: http://projects.jkraemer.net/acts_as_ferret/wiki/DrbServer Jens -- Jens Krämer webit! Gesellschaft für neue Medien mbH Schnorrstraße 76 | 01069 Dresden Telefon +49 351 46766-0 | Telefax +49 351 46766-66 email@example.com | www.webit.de Amtsgericht Dresden | HRB 15422 GF Sven Haubold, Hagen Malessa
on 2007-04-29 20:24
Seem to have such an error. Configuration: Slackware 11/Ruby 1.8.6/Ferret 0.11.4, acts_as_ferret 0.4/ mongrel 1.0.1 I had this problem when mongrel was started under non-privileged user (of course, this user had a full access to app's directory). And no problem running under root...
on 2007-04-29 20:26
BTW, my server is for testing only, so it has no strong workload.