[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559927#action_12559927
]
Michael McCandless commented on LUCENE-1050:
--------------------------------------------
{quote}
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?
{quote}
Actually, I'd make that stronger: you should invert the assertion in that test.
Ie, assert that no exception is hit on writer2.close(), to make sure
double-releasing a lock never throws an exception in the future.
> 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]
