|
After re-evaluating, I'm going to close this as "Won't Fix".
When run in the parallel suite, fsync.js can add several seconds to the latency of operations being run concurrently by other tests (fsync.js runs fsyncLock(), which blocks all writes to the server for up to several seconds). My original concern was that this was causing spurious failures of other tests; however, my current belief is that the tests in the jsCore suite that aren't blacklisted from parallel should be able to tolerate several seconds of increased latency from any operation. If we see spurious failures of tests in the parallel suite that are being run at the same time as fsync.js, then we should re-open this ticket.
Sidenote: I made an assertion in the description of this ticket which is out of date. I stated "the test assumes that reads will succeed while the server is locked, which is not the case if other write operations are running", which is true of versions 2.6 and prior, but not in versions 3.0 and later. Before version 3.0, reads would block if there were any pending writes on an fsyncLock'd server; as of version 3.0, reads no longer block even if there are pending writes.
|