[SERVER-5028] Bug in fsync2.js causes RHEL 64bit Nightly to never finish Created: 21/Feb/12  Updated: 15/Aug/12  Resolved: 27/Feb/12

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Daniel Crosta Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File mongod.log.server-5028    
Issue Links:
Duplicate
duplicates SERVER-5100 writelocktry in replMasterThread may ... Closed
Operating System: ALL
Participants:

 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:



 Comments   
Comment by Eric Milkie [ 27/Feb/12 ]

dup of SERVER-5100

Generated at Thu Feb 08 03:07:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.