lucene.net 2.0在多线程同步下似乎有问题
在我们网站大量线程并发的时候常常报cannot access the commit.lock
查找了lucene的mailing list, 好像这个2.0版本是有问题的,引用如下:
查找了lucene的mailing list, 好像这个2.0版本是有问题的,引用如下:
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:RFaneuf@Inmagic.com]
Sent: Tuesday, August 28, 2007 10:57 PM
To: lucene-net-dev@incubator.apache.org
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; rfaneuf@inmagic.com