[SERVER-25695] ClientCursors shouldn't be aware that they're being managed by the CursorManager Created: 18/Aug/16  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Participants:

 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.


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