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

Using failNonIntentLocksIfWaitNeeded failpoint may leave behind failed lock requests

    • Fully Compatible
    • ALL
    • STM 2019-04-08

      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);
      });
      

            Assignee:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: