[
https://issues.apache.org/jira/browse/LUCENE-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789873#action_12789873
]
Michael McCandless commented on LUCENE-2104:
--------------------------------------------
Seems like two things are being discussed here:
* Should IW.unlock be able to forcefully release a still-in-use
lock? For SimpleFSLockFactory we have no choice but to allow
this, since it's unable to tell if the lock is "really" still
held. But since NativeFSLockFactory can tell, I don't think we
should remove a still-in-use lock? Seems like we leave the choice
to the LF, eg for someone's external LF, it should decide if
forceful removal is allowed.
* If forceful removal is not allowed, should we throw an exception
noting that you failed to forcefully remove the lock? Seems like
we should? Ie, somehow, NativeFSLockFactory should try to acquire
the lock, and if it was already locked, should throw an exception
saying you cannot release it?
> IndexWriter.unlock does does nothing if NativeFSLockFactory is used
> -------------------------------------------------------------------
>
> Key: LUCENE-2104
> URL: https://issues.apache.org/jira/browse/LUCENE-2104
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Shai Erera
> Fix For: 3.1
>
> Attachments: LUCENE-2104.patch
>
>
> If NativeFSLockFactory is used, IndexWriter.unlock will return, silently
> doing nothing. The reason is that NativeFSLockFactory's makeLock always
> creates a new NativeFSLock. NativeFSLock's release first checks if its lock
> is not null. However, only if obtain() is called, that lock is not null. So
> release actually does nothing, and so IndexWriter.unlock does not delete the
> lock, or fail w/ exception.
> This is only a problem in NativeFSLock, and not in other Lock
> implementations, at least as I was able to see.
> Need to think first how to reproduce in a test, and then fix it. I'll work on
> it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
