"Nilesh Bansal" <[EMAIL PROTECTED]> wrote: > We have a web-based application that searches a large lucene index. > This application only creates object of type IndexSearcher only (and > no IndexWriters) for searching the index. After the application runs > for some time (a few hours), I can see lock files in the temp > directory of the form > /opt/tomcat/temp/lucene-5f77ffdc821b3f8e861949e9ecc35a53-commit.lock > The temp dir is set to /opt/tomcat/temp/ as we are using tomcat. > > Since the application is read-only, there is no point in it using the > lock files. These lock files are creating a lot of trouble for me, as > their presence leads to a lock obtained timeout in other threads. It > seems like a bug in lucene. > > The index is updated be a separate process independent of the > web-application once in a while. Currently I am using an independent > shell script that checks for the temp dir for lock files every few > seconds and deletes the lock files if any (to prevent a lock obtained > timeout in other threads).
The commit lock has been problematic in the past and has been removed entirely (so readers are indeed read only) as of release 2.1. Before 2.1, it is very necessary: a reader acquires this lock (creates the file) when it's reading the segments file, to prevent a writer from overwriting the file at the same time. Likewise a writer acquires this lock before overwriting the segments file. However it should exist only briefly, so the fact that you see the lockfile staying around means something bad is happening. Do you ever see the JVM crash? Or any errant exceptions from your readers? These could cause the lock file to be incorrectly left in the filesystem. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
