Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-28327

ClientCursorMonitor can timeout cursors prematurely



    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 3.5.7
    • None
    • Fully Compatible
    • ALL
    • v3.4
    • Query 2017-04-17, Query 2017-05-08
    • 11


      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.


        Issue Links



              charlie.swanson@mongodb.com Charlie Swanson
              james.wahlin@mongodb.com James Wahlin
              0 Vote for this issue
              7 Start watching this issue