The sharding/cursor_timeout.js test sets cursorTimeoutMillis to the same time interval as clientCursorMonitorFrequencySecs. This results in immediate timeout (when the clientcursormon thread wakes up from a clientCursorMonitorFrequencySecs sleep), as the elapsed time interval passed to the timeout check is based on a clientcursormon-level timer and will never be less than clientCursorMonitorFrequencySecs.
In light of the above, the sequence of events that causes this test failure is:
- A find() is run that returns a subset of the result set and leaves an open cursor.
- Just after (on the order of <1ms) the clientcursormon thread wakes up from a 1 second sleep and attempts to kill expired cursors.
- The clientcursormon passes to the kill method its timer value as the elapsed time. In my testing this would be ballpark 1004ms.
- The open cursor is killed after only being open for a few milliseconds.
A quick fix for the test would be to increase cursorTimeoutMillis to 2000. This will give us what I expect was the desired behavior which is kill after 1 second has passed (and will translate to kill between 1 and 2 seconds).
We may also want to consider failing startup when 0 < cursorTimeoutMillis <= (clientCursorMonitorFrequencySecs * 1000) as the test (or at a minimum perform an audit to make sure there are no other tests that setup cursorTimeoutMillis in this manner).