[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559795#action_12559795
]
Hoss Man commented on LUCENE-1050:
----------------------------------
Grant: my take on this is that SpellChecker.clearIndex is in the wrong. it
shouldn't be calling unlock unless it has reason to think there is a "stale
lock" that needs to be closed -- ie: this is a bug in SpellChecker that you
have only discovered because this bug LUCENE-1050 was fixed.
I would suggest a new issue for tracking, and a patch in which
SpellChecker.clearIndex doesn't call unlock unless isLocked returns true. Even
then, it might make sense to catch and ignore LockReleaseFailedException and
let whatever resulting exception may originate from "new IndexWriter" be
returned.
> 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: Michael McCandless
> 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]
