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

ClientCursors shouldn't be aware that they're being managed by the CursorManager

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Querying
    • None
    • Query Execution

    Description

      ClientCursor instances are currently responsible for registering themselves on construction and detecting when they've been killed in destruction to avoid attempting to deregister them from the cursor manager.

      void ClientCursor::init() {
          invariant(_cursorManager);
       
          ...
       
          _cursorid = _cursorManager->registerCursor(this);
       
          ...
      }
       
      ClientCursor::~ClientCursor() {
          ...
       
          if (_cursorManager) {
              // this could be null if kill() was killed
              _cursorManager->deregisterCursor(this);
          }
       
          ...
      }
      

      We may want to take inspiration from the API of the ClusterCursorManager in mongos for refactoring the interface of CursorManager in mongod. One behavior of the existing CursorManager that we likely want to preserve is how the "killCursors" command calls CursorManager::eraseCursor() and is guaranteed to have released the state for that cursor after the response is returned. This differs from how ClusterCursorManager::killCursor() calls ClusterCursorManager::setKillPending() and only releases the state for that cursor after the ClusterCursorCleanupJob processes it.

      Attachments

        Activity

          People

            backlog-query-execution Backlog - Query Execution
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated: