lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless" <>
Subject RE: Lucene 2.1: Lock obtain timed out: SimpleFSLock@<path of index file>
Date Fri, 02 Mar 2007 14:08:52 GMT

"Jerome Chauvin" wrote:
> Thanks Michael for your answer, but following check of our processing, it
> appears all the updates of the index are made in a single thread.
> Actually,
> this kind of exception is thrown during a heavy batch processing. This
> processing is not multi-threaded.

Do you also have an IndexWriter open at the time that you try to the
do deletes through the IndexReader instance?

You have to close that writer before you try to use the IndexReader to
do deletes (and vice/versa).  Only one of these may be opened at a

(This is rather confusing, and is one of reasons that
"deleteDocuments" method was added to IndexWriter in as of 2.1).

> One other think I don't understand is: All the methods accessing the
> index in
> Lucene are synchronized. How can a concurrent access to the index occur?

The synchronization protects Lucene when multiple threads are sharing
a single writer/reader instance (and this use case is totally fine &

To protect the Index against multiple writers (where an IndexReader
doing deletes is considered a "writer"), Lucene uses the write.lock.
Ie a single threaded program can incorrectly try to open multiple
writers against one index, which leads to exactly this exception.

Since writers can in general be on different JVMs or different
machines, Lucene must guard against that as well.  This is why the
"write.lock" [by default] is based in the filesystem and stored [by
default] in the index directory.


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

View raw message