-
Type:
Improvement
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Testing Infrastructure
-
None
-
Fully Compatible
-
TIG B (10/30/15)
In SERVER-21037 and SERVER-21057 certain behavior requires a strategic delay to be easily reproducible. It would be nice to have a fail point that could achieve the same:
diff --git a/src/mongo/db/query/query_yield.cpp b/src/mongo/db/query/query_yield.cpp
index 4e0d463..7edde6e 100644
--- a/src/mongo/db/query/query_yield.cpp
+++ b/src/mongo/db/query/query_yield.cpp
@@ -62,6 +62,10 @@ void QueryYield::yieldAllLocks(OperationContext* txn, RecordFetcher* fetcher) {
// locks). If we are yielding, we are at a safe place to do so.
txn->recoveryUnit()->abandonSnapshot();
+ if (txn->getNS() == "test.foo") {
+ sleepmillis(1000);
+ }
+
// Track the number of yields in CurOp.
CurOp::get(txn)->yielded();
It would be nice, though not strictly necessary, to be able to configure the timeout and/or the namespace for which to cause delays. Finally, some FSM workload that stresses concurrent CRUD operations on documents would be great.
Areas to stress are:
- document growth/shrinkage
- unique (secondary) indexes
- duplicate key violations
- concurrent collection scans
- is related to
-
SERVER-21037 Initial sync can miss documents if concurrent update results in error (mmapv1 only)
-
- Closed
-
-
-
- Closed
-