[ https://issues.apache.org/jira/browse/LUCENENET-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294184#comment-13294184 ]
Pavel Belousov commented on LUCENENET-457: ------------------------------------------ We've alveady developed some additional code which deletes the file write.lock. But I think it's not the right way, because we work with the index without API. The problem occured a lot of times and the index was not corrupted. > Lucene locks directory with index after network related problems > ---------------------------------------------------------------- > > Key: LUCENENET-457 > URL: https://issues.apache.org/jira/browse/LUCENENET-457 > Project: Lucene.Net > Issue Type: Bug > Components: Lucene.Net Core > Environment: Windows Server 2008 > Reporter: Pavel Belousov > > I have a directory for my index in shared folder on another computer in the > network. My service writes data to the index. Sometimes the service gets > network related exceptions like "The specified network name is no longer > available.". After that the service cannot write anything to index because of > lock, even if I delete "write.lock" file manually. Of course, I could restart > the service, but I'd like to avoid it. > I have done a research and have found that Lucene API has > IndexWriter.Unlock() method, but in my case is does not work. > I use NativeFSLockFactory class. Class NativeFSLock has private field > LOCK_HELD with the list of current locks, but in my case (after network > related issues) it has record with the lock (NativeFSLock uses it in Obtain() > method) and I can't delete it through API. I suppose that method > NativeFSLock.Release()(which is called from IndexWriter.Unlock()) should > delete record from the field LOCK_HELD. > May be I'm wrong and there is an appoarch to handle such problems? > At the moment I have implemented the method which deletes the record from > LOCK_HELD through reflection. > Thanks a lot. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira