ClientCursorMonitor will attempt to timeout cursors in a loop, sleeping 4 seconds between executions. On each execution it will capture the time delta between now and the start of the last execution. It increases each cursor's "duration" by this delta and then checks whether a cursor's cumulative delta is over 10 minutes, in which case it will be killed. So the definition of the delta is: timeout cursors execution time + 4 seconds. This is also our margin for error in cursor timeout. A newly created cursor will have its duration incremented by 4 seconds regardless of how long it has been in existence. This means we will timeout cursors which have been alive for 9m 56s to 10m 4s under ideal circumstances.
As part of the timeout mechanism, a collection IS lock is required for each collection with cursors to check. When there is lock contention it can push the increment-delta much higher, pushing out the bounds of when we will timeout. A 2 minute wait would then mean timeout between 7m 56s and 12m 4s. Under extreme circumstances (waiting on locks for 10+ minutes) this will mean timeout of all cursors, regardless of actual lifetime.
- is duplicated by
-
SERVER-26321 Long-running aggregations can artificially time out if the first batch takes more than 10 minutes
-
- Closed
-
-
SERVER-19892 Cursor idle time should be calculated based on time that results were returned, instead of time that request was made
-
- Closed
-
- is related to
-
-
- Closed
-
-
-
- Backlog
-
-
-
- Closed
-