IndexWriter.Init may orphan its write lock in case of exception
---------------------------------------------------------------
Key: LUCENENET-416
URL: https://issues.apache.org/jira/browse/LUCENENET-416
Project: Lucene.Net
Issue Type: Bug
Components: Lucene.Net Core
Affects Versions: Lucene.Net 2.9.2
Environment: .NET 4
Reporter: Håkan Lindqvist
In IndexWriter.Init, if an exception other than IOException is thrown after the
write lock has been acquired, the lock is not released. (See
Index\IndexWriter.cs:1922 for a starting point.)
Specifically, the exception we have seen occuring is
UnauthorizedAccessException, eg "Access to the path 'C:\foo\bar\segments.gen'
is denied".
Stack trace from the UnauthorizedAccessException as mentioned above:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access,
Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions
options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy,
Boolean useLongPath)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share)
at
Lucene.Net.Store.SimpleFSDirectory.SimpleFSIndexInput.Descriptor..ctor(FileInfo
file, FileAccess mode)
at Lucene.Net.Store.SimpleFSDirectory.OpenInput(String name, Int32
bufferSize)
at Lucene.Net.Store.FSDirectory.OpenInput(String name)
at Lucene.Net.Index.SegmentInfos.FindSegmentsFile.Run(IndexCommit commit)
at Lucene.Net.Index.SegmentInfos.Read(Directory directory)
at Lucene.Net.Index.IndexWriter.Init(Directory d, Analyzer a, Boolean
create, Boolean closeDir, IndexDeletionPolicy deletionPolicy, Boolean
autoCommit, Int32 maxFieldLength, IndexingChain indexingChain, IndexCommit
commit)
at Lucene.Net.Index.IndexWriter..ctor(Directory d, Analyzer a, Boolean
create, MaxFieldLength mfl)
I do not know under what circumstances that initial exception occurred but
after this has happened all subsequent attempts at accessing the index will
fail.
It seems that changing the catch statement to release the writelock regardless
of exception type should solve this
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
