[
https://issues.apache.org/jira/browse/LUCENENET-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293985#comment-13293985
]
Itamar Syn-Hershko commented on LUCENENET-457:
----------------------------------------------
I think having the write.lock is expected - it wasn't freed after all. Manually
deleting the file should work. What interests me is whether you experience a
corrupt index as a result of that?
> 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
