-
Type:
Bug
-
Status: Closed
-
Priority:
Major - P3
-
Resolution: Fixed
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
Backwards Compatibility:Fully Compatible
-
Operating System:ALL
-
Backport Completed:
-
Steps To Reproduce:
-
Sprint:Query 2016-12-12
-
Linked BF Score:0
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).