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

MultipleCursorsGetMoreWorks TaskExecutorCursorTest Should Allow getMores on cursors to occur in either order

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.1.0-rc0, 6.0.7, 7.0.0-rc2
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Service Arch
    • Fully Compatible
    • ALL
    • v7.0, v6.0
    • Service Arch 2023-05-29
    • 22

      When TaskExecutorCursor receives a multi-cursor response to the remote, and pre-fetching is enabled, it schedules getMores on each cursor: one via the current TaskExecutorCursor, and one via the constructors of each new TaskExecutorCursor it creates to handle the additional responses (see the call to processResponse here for the first cursor's getMore, and the call to processResponse here for the getMores for each additional cursor created.

      These getMores can reach the network in any order. However, the MultipleCursorsGetMoreWorks test expects a particular ordering of the getMores reaching the network. Before connection-pinning was enabled, this was fine, because the network mocking infrastructure for the non-pinning case is guaranteed to receive the requests in the order they are scheduled by the TaskExecutorCursor response-processing thread. However, the mocking infrastructure for the pinning case is more like the "real" network, in that it can receive these requests out-of-order.

      We should fix the test to be resilient to the getMores for each of the multiple cursors arriving at the network in any order.

            george.wangensteen@mongodb.com George Wangensteen
            george.wangensteen@mongodb.com George Wangensteen
            0 Vote for this issue
            2 Start watching this issue