[jira] Created: (LUCENE-768) Exception in deleteDocument, undeleteAll or setNorm in IndexReader can fail to release write lock on close

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (LUCENE-768) Exception in deleteDocument, undeleteAll or setNorm in IndexReader can fail to release write lock on close

JIRA jira@apache.org
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: 2.0.0, 1.9, 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (LUCENE-768) Exception in deleteDocument, undeleteAll or setNorm in IndexReader can fail to release write lock on close

JIRA jira@apache.org

     [ 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: [hidden email]
For additional commands, e-mail: [hidden email]