SERVER-44180 repl batch applier thread should prompt WiredTigerJournalFlusher thread to flush the journal rather than the oplog visibility thread

1 files changed, 6 insertions, 4 deletions

diff --git a/src/mongo/db/repl/oplog_applier_impl.cpp b/src/mongo/db/repl/oplog_applier_impl.cpp
index eec61306a67..e3ccb71056c 100644
--- a/src/mongo/db/repl/oplog_applier_impl.cpp
+++ b/src/mongo/db/repl/oplog_applier_impl.cpp
@@ -672,11 +672,13 @@ StatusWith<OpTime> OplogApplierImpl::_applyOplogBatch(OperationContext* opCtx,
         }
     }
 
-    // Notify the storage engine that a replication batch has completed. This means that all the
-    // writes associated with the oplog entries in the batch are finished and no new writes with
-    // timestamps associated with those oplog entries will show up in the future.
+    // Tell the storage engine to flush the journal now that a replication batch has completed. This
+    // means that all the writes associated with the oplog entries in the batch are finished and no
+    // new writes with timestamps associated with those oplog entries will show up in the future. We
+    // want to flush the journal as soon as possible in order to free ops waiting with 'j' write
+    // concern.
     const auto storageEngine = opCtx->getServiceContext()->getStorageEngine();
-    storageEngine->replicationBatchIsComplete();
+    storageEngine->triggerJournalFlush();
 
     // Use this fail point to hold the PBWM lock and prevent the batch from completing.
     if (MONGO_unlikely(pauseBatchApplicationBeforeCompletion.shouldFail())) {