Details
-
Bug
-
Resolution: Fixed
-
Major - P3
-
None
-
None
-
Fully Compatible
-
ALL
-
v4.0
-
Storage NYC 2019-02-11
-
69
-
3
Description
If global lock acquisition times out acquiring a ticket, then the constructor will not throw, but the resource will be unlocked. This leads to invariant failure when we attempt to acquire the global lock here then call canAcceptWritesForDatabase() here, which invariants that the lock is held here.
If the caller did not provide a deadline, then they are not checking for lock acquisition failure, so the lock acquisition should throw. Consider applying the following patch:
diff --git a/src/mongo/db/concurrency/lock_state.cpp b/src/mongo/db/concurrency/lock_state.cpp
|
index 11a4028..e7040b8 100644
|
--- a/src/mongo/db/concurrency/lock_state.cpp
|
+++ b/src/mongo/db/concurrency/lock_state.cpp
|
@@ -353,6 +353,12 @@ LockResult LockerImpl::_lockGlobalBegin(OperationContext* opCtx, LockMode mode,
|
dassert(isLocked() == (_modeForTicket != MODE_NONE));
|
if (_modeForTicket == MODE_NONE) {
|
auto acquireTicketResult = _acquireTicket(opCtx, mode, deadline);
|
+ uassert(ErrorCodes::LockTimeout,
|
+ str::stream() << "Unable to acquire ticket with mode '" << mode
|
+ << "' within a max lock request timeout of '"
|
+ << _maxLockTimeout.get()
|
+ << "' milliseconds.",
|
+ acquireTicketResult == LOCK_OK || !_maxLockTimeout);
|
if (acquireTicketResult != LOCK_OK) {
|
return acquireTicketResult;
|
}
|
Attachments
Issue Links
- related to
-
SERVER-39320 lower wiredTigerConcurrentWriteTransactions to 64 in concurrency_simultaneous suites
-
- Closed
-