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

Provide a separate path for delisting operations

    • Service Arch

      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.

            Assignee:
            backlog-server-servicearch [DO NOT USE] Backlog - Service Architecture
            Reporter:
            amirsaman.memaripour@mongodb.com Amirsaman Memaripour
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: