[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559919#action_12559919
]
Michael McCandless commented on LUCENE-1050:
--------------------------------------------
I agree, we should fix it so that if you call release but you do not hold the
lock then no exception is thrown.
But, if you cal l release and you do hold the lock and the release fails then
we should throw the exception.
In fact, NativeFSLockFactory already handles it this way.
Grant, you just have to change that test to not assert that the writer2.close
hit an exception, because according to these new semantics, it should NOT hit
an exception since it is releasing a lock that it no longer holds. If you fix
that do all other tests pass?
> SimpleFSLockFactory ignores error on deleting the lock file
> -----------------------------------------------------------
>
> Key: LUCENE-1050
> URL: https://issues.apache.org/jira/browse/LUCENE-1050
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
> Affects Versions: 2.2
> Reporter: Michael McCandless
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 2.3
>
> Attachments: LUCENE-1050.patch
>
>
> Spinoff from here:
> http://www.gossamer-threads.com/lists/lucene/java-user/54438
> The Lock.release for SimpleFSLockFactory ignores the return value of
> lockFile.delete(). I plan to throw a new LockReleaseFailedException,
> subclassing from IOException, when this returns false. This is a very minor
> change to backwards compatibility because all methods in Lucene that release
> a lock already throw IOException.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
