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

Enforce implicit rules around use of OperationContext on a RemoteCommandRequest

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None
    • None
    • Service Arch
    • Service Arch 2024-02-05, Service Arch 2024-02-19

    Description

      When a RemoteCommandRequest has an OperationContext member, that member is only accessed on the thread that calls scheduleRemoteCommand/NetworkInterface::startCommand. The general historical rule (see this comment) is that the client-thread owning the OperationContext should be the one to call scheduleRemoteCommand, to ensure that the OperationContext is not destroyed before it is read off the RemoteCommandRequest.

      Generally, it is not safe to call scheduleRemoteCommand with an RCR with an OperationContext from a different thread, unless there is additional synchronization that ensures the OperationContext isn't destroyed.

      We should consider enforcing these rules in code, i.e. by insisting that the thread-local client of the thread calling scheduleRemoteCommand owns the OperationContext, etc.

      Attachments

        Activity

          People

            george.wangensteen@mongodb.com George Wangensteen
            george.wangensteen@mongodb.com George Wangensteen
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated: