Thanks for letting me know.. Ross
-----Original Message----- From: DIGY [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 5:20 PM To: [email protected] Subject: RE: Unexpected behavior in Lucene locking code 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 DIGY -----Original Message----- From: Ross Faneuf [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 28, 2007 10:57 PM To: [email protected] 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=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Message : The process cannot access the file 'C:\...\system\index\lock\lucene-82b3c5ad936757ece94a8582252daee7-commit .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 maybeFullPath) 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 end) 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; ReaderWriterLock _indexReaderLock.AcquireWriterLock(Timeout.Infinite); try { indexWriter = GetIndexWriter(); Document doc = LuceneIndexHelper.GetDocument(ct, ctData); indexWriter.AddDocument(doc); } catch (Exception e) { ... } finally { if (indexWriter != null) { indexWriter.Close(); indexWriter = null; } _indexReaderLock.ReleaseWriterLock(); } We note, though, the IndexReader code also acquires the same lock - for instance in: private static IndexReader Open(Directory directory, bool closeDirectory) { lock (directory) { // in- & inter-process sync return (IndexReader) new AnonymousClassWith(directory, closeDirectory, directory.MakeLock(IndexWriter.COMMIT_LOCK_NAME), IndexWriter.COMMIT_LOCK_TIMEOUT).Run(); } } 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; [EMAIL PROTECTED]
