lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless" <>
Subject Re: Lock files in a read-only application
Date Sun, 01 Apr 2007 01:03:16 GMT
"Nilesh Bansal" <> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message