Lucene - Core
  1. Lucene - Core
  2. LUCENE-1885

NativeFSLockFactory.makeLock(...).isLocked() does not work

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.9
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      IndexWriter.isLocked() or IndexReader.isLocked() do not work with NativeFSLockFactory.

      The problem is, that the method NativeFSLock.isLocked() just checks if the same lock instance was locked before (lock != null). If the LockFactory created a new lock instance, this always returns false, even if its locked.

        Issue Links

          Activity

          Hide
          Uwe Schindler added a comment -

          I will solve this together with LUCENE-1877.

          To test, if lock is obtained, you have to try locking and release the lock after that (if the lock was obtained):

            public synchronized boolean isLocked() {
              // the test for is isLocked is not directly possible with native file locks:
              
              // if we have a lock instance in this class, it is for sure locked:
              if (lockExists()) return true;
              
              // else try to obtain and release (if was locked) the lock to test
              try {
                boolean obtained = obtain();
                if (obtained) release();
                return !obtained;
              } catch (IOException ioe) {
                return false;
              }    
            }
          

          The method lockExists contains the same like isLocked contained before and is used instead to check if a local lock instance is available (as quick break-out).

          There is no patch as it is included in my work for 1877 and hard to unwire.

          Show
          Uwe Schindler added a comment - I will solve this together with LUCENE-1877 . To test, if lock is obtained, you have to try locking and release the lock after that (if the lock was obtained): public synchronized boolean isLocked() { // the test for is isLocked is not directly possible with native file locks: // if we have a lock instance in this class, it is for sure locked: if (lockExists()) return true ; // else try to obtain and release ( if was locked) the lock to test try { boolean obtained = obtain(); if (obtained) release(); return !obtained; } catch (IOException ioe) { return false ; } } The method lockExists contains the same like isLocked contained before and is used instead to check if a local lock instance is available (as quick break-out). There is no patch as it is included in my work for 1877 and hard to unwire.
          Hide
          Michael McCandless added a comment -

          Nice catch Uwe!

          Show
          Michael McCandless added a comment - Nice catch Uwe!
          Hide
          Uwe Schindler added a comment -

          Thanks!

          It was not so hard. After changing the default lock factory, a lot of tests were failing because of this.

          Show
          Uwe Schindler added a comment - Thanks! It was not so hard. After changing the default lock factory, a lot of tests were failing because of this.
          Hide
          Uwe Schindler added a comment -

          The new patch in LUCENE-1877 changes the isLocked() method to shortcut, if no lock file is present. In this case, without a lockfile, it cannot be not locked. This prevent NativeFSLock for creating the lock short time without really using it.

          Show
          Uwe Schindler added a comment - The new patch in LUCENE-1877 changes the isLocked() method to shortcut, if no lock file is present. In this case, without a lockfile, it cannot be not locked. This prevent NativeFSLock for creating the lock short time without really using it.
          Hide
          Uwe Schindler added a comment -

          Committed revision: 811157

          Show
          Uwe Schindler added a comment - Committed revision: 811157

            People

            • Assignee:
              Uwe Schindler
              Reporter:
              Uwe Schindler
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development