Hes Siemelink wrote:
It happens from time to time... but I don't know how to reproduce it.
Rebuilding this particular index unfortunately takes about 10 hrs, so it's
not feasable to delete the index and rebuild it when this happens... our
users would be missing a lot of search results then!
There are a couple of workaround strategies I could follow (using separate
indexes for updating and querying for example), but I would like to know
what's causing this so I can make a fix with less impact on my code.
This exception typically means that the segments file is referring to
a segment that doesn't exist in the filesytem (eg was deleted or lost
or something).
The most common cause of this (I think) is locking not working
properly. Ie, a reader is opening segments at the same time that a
writer is writing segments (and deleting old ones). Lucene's commit
lock exists to prevent this from happening.
Is your application all running under one JVM (sounds like yes)? Ie,
in one JVM you have one thread doing updating and then multiple
threads searching.
What kind of filesystem is your index stored on (eg, local or NFS)?
And how about the lock directory (normally defaults to the JVMs
java.io.tmpdir property)?
Are you sure there was no prior "root cause" exception, eg on the
updating thread?
When this exception happens, does it eventually go away on its own or
is the index permanantly corrupt (and you have to build another one)?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
