[SERVER-28327] ClientCursorMonitor can timeout cursors prematurely Created: 15/Mar/17  Updated: 26/Apr/18  Resolved: 03/May/17

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 3.5.7

Type: Bug Priority: Major - P3
Reporter: James Wahlin Assignee: Charlie Swanson
Resolution: Done Votes: 0
Labels: bkp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Duplicate
is duplicated by SERVER-26321 Long-running aggregations can artific... Closed
is duplicated by SERVER-19892 Cursor idle time should be calculated... Closed
Related
is related to SERVER-28328 ClientCursor::_idleAgeMillis update i... Closed
is related to SERVER-28942 sort by shard key or prefix of shard ... Backlog
is related to SERVER-19892 Cursor idle time should be calculated... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.4
Sprint: Query 2017-04-17, Query 2017-05-08
Participants:
Case:
Linked BF Score: 11

 Description   

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.



 Comments   
Comment by Githook User [ 03/May/17 ]

Author:

{u'username': u'cswanson310', u'name': u'Charlie Swanson', u'email': u'charlie.swanson@mongodb.com'}

Message: SERVER-28327 Revamp cursor timeout logic.

Instead of tracking the number of idle milliseconds, each ClientCursor
tracks its last time of use. This also resolves related issues
SERVER-28328 and SERVER-19892.
Branch: master
https://github.com/mongodb/mongo/commit/7759c61a35f835aa109131b8f1575f0e1879cba0

Generated at Thu Feb 08 04:17:48 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.