-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Internal Code
-
Server Programmability
SERVER-47802 enabled an instance of ServiceStateMachine to postpone destruction of operations (i.e., instances of OperationContext) until after sending responses to the client. This enables partially moving the cost of running opCtx destructor off of the critical path.
Currently, ServiceStateMachine kills and delists operations before sinking the response to postpone destruction without impacting the visible state of running operations (e.g., the currentOp output). Killing the operation is currently necessary to ensure any task scheduled on the opCtx baton is drained and the operation cannot be reused.
However, killing an operation also notifies all killOpListeners (see here), callbacks that are invoked whenever an operation is killed – and killing operations to postpone their destruction can be very confusing to killOpListeners.
for (const auto listener : _killOpListeners) { try { listener->interrupt(opCtx->getOpID()); } catch (...) { std::terminate(); } }
This ticket should investigate the possibility of providing a separate path for delisting operations in ServiceStateMachine without killing them (e.g., running killOpListeners). Next, it should introduce a new interface to delist operations and replace the usage of killAndDelistOperation in ServiceStateMachine if doing so doesn't violate any design invariants.
- is related to
-
SERVER-47802 Destroy opCtx after responding to clients
- Closed
-
SERVER-57016 Consider changing MozJSScriptEngine to not log "kill" events for unrecognized OperationContexts
- Closed
- related to
-
SERVER-70960 Fix the mismatch between registering operations under the JS engine and their interruptibility
- Backlog