Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-2421

Hardening of NativeFSLock

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 2.9.3, 3.0.2, 3.1, 4.0-ALPHA
    • core/index
    • None
    • New, Patch Available

    Description

      NativeFSLock create a test lock file which its name might collide w/ another JVM that is running. Very unlikely, but still it happened a couple of times already, since the tests were parallelized. This may result in a false exception thrown from release(), when the lock file's delete() is called and returns false, because the file does not exist (deleted by another JVM already). In addition, release() should give a second attempt to delete() if it fails, since the file may be held temporarily by another process (like AntiVirus) before it fails. The proposed changes are:

      1) Use ManagementFactory.getRuntimeMXBean().getName() as part of the test lock name (should include the process Id)
      2) In release(), if delete() fails, check if the file indeed exists. If it is, let's attempt a re-delete() few ms later.
      3) If (3) still fails, throw an exception. Alternatively, we can attempt a deleteOnExit.

      I'll post a patch later today.

      Attachments

        1. LUCENE-2421.patch
          3 kB
          Shai Erera
        2. LUCENE-2421.patch
          3 kB
          Shai Erera
        3. LUCENE-2421.patch
          5 kB
          Shai Erera
        4. LUCENE-2421.patch
          4 kB
          Shai Erera
        5. LUCENE-2421-2.patch
          1 kB
          Shai Erera

        Activity

          People

            shaie Shai Erera
            shaie Shai Erera
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: