lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DIGY" <>
Subject RE: Unexpected behavior in Lucene locking code
Date Tue, 28 Aug 2007 21:20:28 GMT
Hi Ross,

In previous versions, there was a bug in "SimpleFSLockFactory.Obtain" method
where two or more IndexWriters could access the same index simultaneously.

The reason of your exception may be that bug.It is fixed in LUCENENET-74 and
will be ready in v2.1


-----Original Message-----
From: Ross Faneuf [] 
Sent: Tuesday, August 28, 2007 10:57 PM
Subject: Unexpected behavior in Lucene locking code

We are using Lucene.Net-2.0 final-004, and have encountered intermittent
errors in the locking code when running under a heavy load in a
multi-process, multi-thread environment. This is a partial call stack
from one of the errors:


Type : System.IO.IOException, mscorlib, Version=,
Culture=neutral, PublicKeyToken=b77a5c561934e089

Message : The process cannot access the file
.lock' because it is being used by another process.

Source : mscorlib

Help link : 

Data : System.Collections.ListDictionaryInternal

TargetSite : Void WinIOError(Int32, System.String)

Stack Trace :    at System.IO.__Error.WinIOError(Int32 errorCode, String

   at System.IO.File.Delete(String path)

   at Lucene.Net.Store.FSDirectory.AnonymousClassLock.Release()

   at Lucene.Net.Store.Lock.With.Run()

   at Lucene.Net.Index.IndexWriter.MergeSegments(Int32 minSegment, Int32

   at Lucene.Net.Index.IndexWriter.FlushRamSegments()

   at Lucene.Net.Index.IndexWriter.Close()


This error is from a process which is updating a Lucene index.


Our code which calls IndexWriter is:


        IndexWriter indexWriter = null;




                        indexWriter = GetIndexWriter();

                        Document doc = LuceneIndexHelper.GetDocument(ct,



                catch (Exception e)






                        if (indexWriter != null)



                                indexWriter = null;





We note, though, the IndexReader code also acquires the same lock - for
instance in:


        private static IndexReader Open(Directory directory, bool


                lock (directory)


                        // in- & inter-process sync

                        return (IndexReader) new
AnonymousClassWith(directory, closeDirectory,




Is the purpose of this lock to prevent an index update while a Read is
in progress? Is it possible that under the right load and complexity
conditions, this lock attempt interferes with lock handling in
IndexWriter? I note that IndexWriter operation actually take this lock
multiple times, using the various AnonymousClassWith<n> objects, and it
appears possible for the IndexReader lock to be acquired in between the
IndexWriter locked operations. Any insight into the origins of this
problem would be helpful.


Ross Faneuf;



View raw message