SERVER-59929 Limit the blocking of split/merge behind other metadata operations to 5 seconds

(cherry picked from commit ed7cca61938ee12f5a9cbe870af096987c662f5c)

1 files changed, 11 insertions, 4 deletions

diff --git a/src/mongo/db/s/active_migrations_registry.cpp b/src/mongo/db/s/active_migrations_registry.cpp
index 3a13ef338af..9b6394b05ae 100644
--- a/src/mongo/db/s/active_migrations_registry.cpp
+++ b/src/mongo/db/s/active_migrations_registry.cpp
@@ -98,10 +98,17 @@ StatusWith<ScopedSplitMergeChunk> ActiveMigrationsRegistry::registerSplitOrMerge
     OperationContext* opCtx, const NamespaceString& nss, const ChunkRange& chunkRange) {
     stdx::unique_lock<Latch> ul(_mutex);
 
-    opCtx->waitForConditionOrInterrupt(_chunkOperationsStateChangedCV, ul, [&] {
-        return !(_activeMoveChunkState && _activeMoveChunkState->args.getNss() == nss) &&
-            !_activeSplitMergeChunkStates.count(nss);
-    });
+    // In order for splits to not block for too long behind a potential chunk migration, limit the
+    // duration of waiting for conflicting operations to at most 5 seconds. Otherwise, due to the
+    // fact that chunk splits block write operations on the MongoS it is possible that the write
+    // workload gets a really long stall.
+    const auto deadline = opCtx->getServiceContext()->getFastClockSource()->now() + Seconds{5};
+    if (!opCtx->waitForConditionOrInterruptUntil(_chunkOperationsStateChangedCV, ul, deadline, [&] {
+            return !(_activeMoveChunkState && _activeMoveChunkState->args.getNss() == nss) &&
+                !_activeSplitMergeChunkStates.count(nss);
+        })) {
+        return {ErrorCodes::LockBusy, "Timed out waiting for concurrent migration to complete"};
+    }
 
     auto [it, inserted] =
         _activeSplitMergeChunkStates.emplace(nss, ActiveSplitMergeChunkState(nss, chunkRange));