[
https://issues.apache.org/jira/browse/LUCENE-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-768.
---------------------------------------
Resolution: Fixed
> Exception in deleteDocument, undeleteAll or setNorm in IndexReader can fail
> to release write lock on close
> ----------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-768
> URL: https://issues.apache.org/jira/browse/LUCENE-768
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: 1.9, 2.0.0, 2.0.1, 2.1
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
> Fix For: 2.1
>
>
> I hit this while working on LUCENE-140
> We have 3 cases in the IndexReader methods above where we have this pattern:
> if (directoryOwner) acquireWriteLock();
> doSomething();
> hasChanges = true;
> The problem is if you hit an exception in doSomething(), and hasChanges was
> not already true, then hasChanges will not have been set to true yet the
> write lock is held. If you then try to close the reader without making any
> other changes, then the write lock is not released because in
> IndexReader.close() (well, in commit()) we only release write lock if
> hasChanges is true.
> I think the simple fix is to swap the order of hasChanges = true and
> doSomething(). I already fixed one case of this under LUCENE-140 commit
> yesterday; I will fix the other two under this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
