Info
[j5:c:prim] | 2022-11-15T17:57:43.125+00:00 F ASSERT
23079
[conn26] "Invariant failure","attr":
{"expr":"request->recursiveCount > 0","file":"src/mongo/db/concurrency/lock_manager.cpp","line":539}
mongo::LockerImpl::_lockBegin(mongo::OperationContext*, mongo::ResourceId, mongo::LockMode)
mongo::LockerImpl::lock(mongo::OperationContext*, mongo::ResourceId, mongo::LockMode, mongo::Date_t)
mongo::Lock::ResourceLock::_lock(mongo::LockMode, mongo::Date_t)
mongo::telemetry::getTelemetryStoreForRead(mongo::ServiceContext const*)
mongo::telemetry::(anonymous namespace)::LockedMetrics::get(mongo::OperationContext const*, mongo::BSONObj const&)
mongo::telemetry::recordExecution(mongo::OperationContext const*, mongo::OpDebug const&, bool)
mongo::(anonymous namespace)::FindCmd::Invocation::run(mongo::OperationContext*, mongo::rpc::ReplyBuilderInterface*)
Top User Comments
xgen-internal-githook commented on Mon, 28 Nov 2022 19:55:26 +0000:
Author:
{'name': 'Jess Balint', 'email': 'jbalint@gmail.com', 'username': 'jbalint'}
Message: SERVER-71390 locking fix
Branch: master
https://github.com/mongodb/mongo/commit/507288cdeed26adbdab4eccd66cb48b73d96559e
david.storch commented on Wed, 16 Nov 2022 22:55:10 +0000:
What's the rationale for the telemetry store having its own LockerImpl instance? I assumed that the telemetry store would work like the plan cache – namely, it would be initialized on process startup before we begin collecting telemetry. During steady-state operation, the concurrency control would be implemented using our Partitioned utility, which under the hood has a vector of mutexes.
