Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 4.10, 5.0, 6.0
    • core/index
    • None
    • New

    Description

      This method used to be necessary, when our locking impls were buggy, but it's a godawful dangerous method: it invites index corruption.

      I think we should remove it.

      Apps that for some scary reason really need it can do their own thing...

      Attachments

        1. LUCENE-6060.patch
          12 kB
          Michael McCandless

        Activity

          tomoko Tomoko Uchida added a comment -

          This issue was moved to GitHub issue: #7122.

          tomoko Tomoko Uchida added a comment - This issue was moved to GitHub issue: #7122 .
          anshum Anshum Gupta added a comment -

          Bulk close after 5.0 release.

          anshum Anshum Gupta added a comment - Bulk close after 5.0 release.

          Well, Solr still has the unlockOnStartup; I wasn't sure what to do with that so I left it for now and opened SOLR-6737.

          Most Lucene apps shouldn't be using the legacy SimpleFSLockFactory, and if they are 1) they must already be dealing with the "remove lock on startup", 2) if they are doing so via IndexWriter.unlock, they will see the deprecation/compilation error on upgrade, dig in CHANGES, find this issue, and then have to do their own scary things: I think this is healthy.

          I don't really like the deleteOnExit method.

          mikemccand Michael McCandless added a comment - Well, Solr still has the unlockOnStartup; I wasn't sure what to do with that so I left it for now and opened SOLR-6737 . Most Lucene apps shouldn't be using the legacy SimpleFSLockFactory, and if they are 1) they must already be dealing with the "remove lock on startup", 2) if they are doing so via IndexWriter.unlock, they will see the deprecation/compilation error on upgrade, dig in CHANGES, find this issue, and then have to do their own scary things: I think this is healthy. I don't really like the deleteOnExit method.

          Are there still reasons for not using deleteOnExit in SimpleFSLockFactory? I feel that removing the unlockOnStartup option while there are still cases where the index is left locked could bite people when upgrading.

          tflobbe Tomas Eduardo Fernandez Lobbe added a comment - Are there still reasons for not using deleteOnExit in SimpleFSLockFactory? I feel that removing the unlockOnStartup option while there are still cases where the index is left locked could bite people when upgrading.

          I think SimpleFSLockFactory is still able to leave leftover write.lock in the index ... it doesn't use deleteOnExit, so that JVM bug doesn't apply to it.

          mikemccand Michael McCandless added a comment - I think SimpleFSLockFactory is still able to leave leftover write.lock in the index ... it doesn't use deleteOnExit, so that JVM bug doesn't apply to it.

          in fact this can no longer happen with NativeFSLockFactory

          What about SimpleFSLockFactory? That was the one that would have problems in JVM crashes right? The Java bug linked in the javadoc is old and has been fixed long ago, I guess that means that it's now safe and shouldn't leave a write.lock file even if JVM crashes

          tflobbe Tomas Eduardo Fernandez Lobbe added a comment - in fact this can no longer happen with NativeFSLockFactory What about SimpleFSLockFactory ? That was the one that would have problems in JVM crashes right? The Java bug linked in the javadoc is old and has been fixed long ago, I guess that means that it's now safe and shouldn't leave a write.lock file even if JVM crashes

          Maybe just open a new issue in SOLR!

          SOLR-6737

          mikemccand Michael McCandless added a comment - Maybe just open a new issue in SOLR! SOLR-6737

          I deprecated IndexWriter.unlock in 4.10.x ... I'll open a follow-on Solr issue.

          mikemccand Michael McCandless added a comment - I deprecated IndexWriter.unlock in 4.10.x ... I'll open a follow-on Solr issue.

          Commit 1639350 from mikemccand in branch 'dev/branches/lucene_solr_4_10'
          [ https://svn.apache.org/r1639350 ]

          LUCENE-6060: deprecate IndexWriter.unlock

          jira-bot ASF subversion and git services added a comment - Commit 1639350 from mikemccand in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1639350 ] LUCENE-6060 : deprecate IndexWriter.unlock

          Commit 1639330 from mikemccand in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1639330 ]

          LUCENE-6060: remove IndexWriter.unlock

          jira-bot ASF subversion and git services added a comment - Commit 1639330 from mikemccand in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1639330 ] LUCENE-6060 : remove IndexWriter.unlock

          Commit 1639329 from mikemccand in branch 'dev/trunk'
          [ https://svn.apache.org/r1639329 ]

          LUCENE-6060: remove IndexWriter.unlock

          jira-bot ASF subversion and git services added a comment - Commit 1639329 from mikemccand in branch 'dev/trunk' [ https://svn.apache.org/r1639329 ] LUCENE-6060 : remove IndexWriter.unlock
          uschindler Uwe Schindler added a comment -

          Maybe just open a new issue in SOLR!

          uschindler Uwe Schindler added a comment - Maybe just open a new issue in SOLR!

          I was nervous about changing Solr's behavior here; maybe we can pursue that in a different issue ...

          mikemccand Michael McCandless added a comment - I was nervous about changing Solr's behavior here; maybe we can pursue that in a different issue ...
          uschindler Uwe Schindler added a comment -

          +1 - throw it away!

          We should also fix this Solr part! Forcefully unlocking solr should also go away - in fact this can no longer happen with NativeFSLockFactory because the lock is gone once all writers finished or crushed their JVM!

          uschindler Uwe Schindler added a comment - +1 - throw it away! We should also fix this Solr part! Forcefully unlocking solr should also go away - in fact this can no longer happen with NativeFSLockFactory because the lock is gone once all writers finished or crushed their JVM!

          Simple patch...

          mikemccand Michael McCandless added a comment - Simple patch...

          People

            mikemccand Michael McCandless
            mikemccand Michael McCandless
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: