Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-40420

Using failNonIntentLocksIfWaitNeeded failpoint may leave behind failed lock requests

    XMLWordPrintable

    Details

      Description

      The failNonIntentLocksIfWaitNeeded failpoint assumes that LockerImpl::unlockGlobal() will eventually be called before the LockerImpl is destructed. This was found not to be the case with the RESOURCE_METADATA lock acquired for capped collections via a ResourceLock instance.

      if (_needCappedLock) {
          // X-lock the metadata resource for this capped collection until the end of the WUOW. This
          // prevents the primary from executing with more concurrency than secondaries.
          // See SERVER-21646.
          Lock::ResourceLock heldUntilEndOfWUOW{
              opCtx->lockState(), ResourceId(RESOURCE_METADATA, _ns.ns()), MODE_X};
      }
      

      Instead, the MONGO_FAIL_POINT(failNonIntentLocksIfWaitNeeded) blocks should be guarded by the unlockOnErrorGuard to ensure LockerImpl::_unlockImpl() gets called after we uassert().

      // Clean up the state on any failed lock attempts.
      auto unlockOnErrorGuard = makeGuard([&] {
          LockRequestsMap::Iterator it = _requests.find(resId);
          _unlockImpl(&it);
      });
      

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: