Lucene - Core
  1. Lucene - Core
  2. LUCENE-2663

wrong exception from NativeFSLockFactory (LIA2 test case)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1, 4.0-ALPHA
    • Component/s: core/index
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      As part of integrating Lucene In Action 2 test cases (LUCENE-2661), I found one of the test cases fail

      the test is pretty simple, and passes on 3.0. The exception you get instead (LockReleaseFailedException) is
      pretty confusing and I think we should fix it.

        Issue Links

          Activity

          Robert Muir created issue -
          Robert Muir made changes -
          Field Original Value New Value
          Attachment LUCENE-2663_test.patch [ 12455396 ]
          Hide
          Robert Muir added a comment -

          for trunk, just change the test to use MockAnalyzer instead of simple... i made the patch from 3x.

          Show
          Robert Muir added a comment - for trunk, just change the test to use MockAnalyzer instead of simple... i made the patch from 3x.
          Robert Muir made changes -
          Link This issue relates to LUCENE-2661 [ LUCENE-2661 ]
          Hide
          Uwe Schindler added a comment -

          May there be a randomization issue. If both index writers use a different LockFacory, it can easy fail! So at least for one test run, the LockFactory should be identical, else the locking can produce wrong failures/messages, as SimpleFSLock and NativeFSLock can interact very limited, but there are only some security checks, so locking will fail if you mix the implementations.

          Show
          Uwe Schindler added a comment - May there be a randomization issue. If both index writers use a different LockFacory, it can easy fail! So at least for one test run, the LockFactory should be identical, else the locking can produce wrong failures/messages, as SimpleFSLock and NativeFSLock can interact very limited, but there are only some security checks, so locking will fail if you mix the implementations.
          Hide
          Robert Muir added a comment -

          The test isnt random. it uses FSDirectory.open

          Show
          Robert Muir added a comment - The test isnt random. it uses FSDirectory.open
          Hide
          Uwe Schindler added a comment -

          Sorry, you are right. The exception throws is clearly wrong Maybe its related to Shai's changes in NativeFSLockFactory (which is the default)?

          Show
          Uwe Schindler added a comment - Sorry, you are right. The exception throws is clearly wrong Maybe its related to Shai's changes in NativeFSLockFactory (which is the default)?
          Hide
          Michael McCandless added a comment -

          I think it is the recent changes to NativeFSLockFactory...

          IW tries to first clear the lock, if create=true, and that attempt is causing the exception. Really this is a holdover from SimpleFSLockFactory, which can leave orphan'd locks... so maybe somehow we shouldn't do this for other lock factories?

          Show
          Michael McCandless added a comment - I think it is the recent changes to NativeFSLockFactory... IW tries to first clear the lock, if create=true, and that attempt is causing the exception. Really this is a holdover from SimpleFSLockFactory, which can leave orphan'd locks... so maybe somehow we shouldn't do this for other lock factories?
          Hide
          Michael McCandless added a comment -

          I think we should remove the call inside IW to dir.clearLock? This is a holdover from when SimpleFSLockFactory was the default. And, I think it's devious/dangerous w/ that lock factory since that lock factory lets you simply erase the lock out from under another open IW. Ie that call masks bugs.

          All tests pass when I remove it, and, the LIA lock test also passes.

          Show
          Michael McCandless added a comment - I think we should remove the call inside IW to dir.clearLock? This is a holdover from when SimpleFSLockFactory was the default. And, I think it's devious/dangerous w/ that lock factory since that lock factory lets you simply erase the lock out from under another open IW. Ie that call masks bugs. All tests pass when I remove it, and, the LIA lock test also passes.
          Michael McCandless made changes -
          Assignee Michael McCandless [ mikemccand ]
          Michael McCandless made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Mark Thomas made changes -
          Workflow jira [ 12521364 ] Default workflow, editable Closed status [ 12564315 ]
          Mark Thomas made changes -
          Workflow Default workflow, editable Closed status [ 12564315 ] jira [ 12585661 ]
          Hide
          Grant Ingersoll added a comment -

          Bulk close for 3.1

          Show
          Grant Ingersoll added a comment - Bulk close for 3.1
          Grant Ingersoll made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          9d 14h 57m 1 Michael McCandless 03/Oct/10 10:14
          Resolved Resolved Closed Closed
          178d 6h 35m 1 Grant Ingersoll 30/Mar/11 16:50

            People

            • Assignee:
              Michael McCandless
              Reporter:
              Robert Muir
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development