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

Implement cancellation contract for async_rpc operations

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 6.3.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Fully Compatible
    • Service Arch 2022-12-26, Service Arch 2022-12-12, Service Arch 2023-01-09, Service Arch 2023-01-23, Service Arch 2023-02-06
    • 20

      We now have a defined cancellation contract that the async_rpc API should implement: 

      The RPC library should append an OperationKey (GUID) to all operations it sends. When those operations are canceled, if networking has begun for that operation (i.e. any data may have been sent), the RPC unconditionally sends fire-and-forget _killOperations for that OperationKey to the same remote node. 

      Since the library currently delegates to TaskExecutor/NetworkInterfaceTL to perform networking, implementing this cancellation contract will first involve cancelling any ongoing network interface operations, if they have begun. This is possible by simply using the cancellation token passed to the network interface, and should happen automatically if the async_rpc API's user cancels the token they passed in. Then, the async_rpc API should inspect the NetworkInterface operation response and see if it succeeded or successfully cancelled; if it succeeded, the async_rpc layer needs to send killOperations itself.

      If the NetworkInterface operation was cancelled successfully, the network interface may or may not have sent the required _killOperations. Here, we should do a short/timeboxed investigation on the best solution - one thing we could do is fix the network interface to always send _killOperations in this case, if that fix is small and simple. If it is not, we could have the async_rpc api always send it, even if it ends up being a duplicate _killOperations. 

            Assignee:
            amirsaman.memaripour@mongodb.com Amirsaman Memaripour
            Reporter:
            george.wangensteen@mongodb.com George Wangensteen
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: