The drop2.js test command can fail in particular atypical timing of the parallel shells.

drop2.js uses a count command with a infinite $where clause in order to block a drop operation so that we may check whether killOp can be used on the drop collection command. We believe this test is attempting to confirm that we are able to issue a killOp on a drop collection command, but that the operation is not interrupted, which prior to SERVER-1818 could leave the database in an inconsistent state.

On a correct execution, the count command acquires a read lock on the collection, preventing it from being dropped. However, if the count command yields, it releases the collection lock. This allowed the collection to drop before we can observe it in the currentOp output in drop2.js.

max.hirschhorn suggests that we rewrite this test in order to:

1. Issue a fsyncLock command.
2. Execute a drop collection, wait until the currentOp output indicates it is waiting for locks.
3. Issue a killOp for the drop operation.
4. Issue fsyncUnlock.
5. Check that the drop operation was not killed, and that the collection was dropped successfully.

This removes the dependency on the yielding behavior of the count command. We have inspected the code path and confirmed that the only call to checkForInterrupt() during the execution of a drop command is here, before the drop command attempts to acquire locks here.