Balancer::_moveChunks can submit several asynchonous moveChunk requests concurrently. Each one of these calls to BalancerCommandsSchedulerImpl::requestMoveChunk will use the same opCtx. BalancerCommandsSchedulerImpl::requestMoveChunk will return a SemiFuture, that stores a copy of the opCtx pointer, and as part of its execution will use that opCtx to call processCommandResponse, which will call setLastOpToSystemLastOpTime which takes locks and thus alters the lock state of that opCtx. Thus several threads can concurently alter the opCtx's state, and this can lead to tripping invariants.
setLastOpToSystemLastOpTime should not be called from the executor callbacks.
- is caused by
-
SERVER-61113 _configsvrMoveChunk does not gossip the proper operationTime back to the router
- Closed
- is depended on by
-
SERVER-43099 Reenable random chunk migration failpoint for concurrency with_balancer suites
- Closed