Details
-
Bug
-
Resolution: Duplicate
-
Major - P3
-
None
-
None
-
None
-
ALL
Description
I believe there is a bug in jstests/fsync2.js such that the test hangs and blocks future builds from being scheduled. I believe the problematic code is:
assert.commandWorked( d.runCommand( {fsync:1, lock: 1 } ) );
|
|
|
for ( i=0; i<200; i++) {
|
assert.eq(1, db.fsync2.count());
|
sleep(1);
|
}
|
|
|
db.fsync2.save( {x:1} );
|
As I understand it, once a database is fsync/locked and a write comes in (the save on the last line), all reads and writes are blocked until the fsync/lock is un-done. Since the Mongo shell does safe-mode writes by default, control will never return to the jstest after the .save() line (it will block indefinitely, or at least seems to be doing so).
Possibly related cases:
Attachments
Issue Links
- duplicates
-
SERVER-5100 writelocktry in replMasterThread may make reads hang
-
- Closed
-