lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nilesh Bansal" <>
Subject Re: Lock files in a read-only application
Date Sun, 01 Apr 2007 01:30:29 GMT
Thanks for your response. Is there a way that I can disable these read
locks without upgrading to 2.1. Our application uses its own custom
locking mechanism, so that lucene locking is actually redundant. We
are currently using Lucene version 2.0.

The application has multiple threads (different web requests) reading
the same index simultaneously (say 20 concurrent threads). Can that be
a reason of this problem. Sometimes the lockfiles remain there for
long periods of time (more than a few minutes, which is bad).

Yes, JVM sometimes crashes when it runs out of memory. There should be
someway that the lock files are removed after such crash (any fixes is


On 3/31/07, Michael McCandless <> wrote:
> "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.
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Nilesh Bansal.

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

View raw message