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

getMore on exchange does not respect maxTimeMs if the cursor is waiting for different consumer

    • Type: Icon: Bug Bug
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Query Execution
    • ALL
    • Hide

      You can reproduce this behavior somewhat consistently with the exchange_producer.js FSM workload, if you reduce the buffer size to ~1000.

      Show
      You can reproduce this behavior somewhat consistently with the exchange_producer.js FSM workload, if you reduce the buffer size to ~1000.
    • QE 2024-05-13, QE 2024-05-27, QE 2024-06-10, QE 2024-06-24, QE 2024-07-08, QE 2024-07-22, QE 2024-08-05, QE 2024-08-19, QE 2024-09-02, QE 2024-09-16, QE 2024-09-30, QE 2024-10-14, QI 2024-02-19, QI 2024-03-04

      In the exchange operator, it's possible that consumer A may fill its buffer, and consumer B is waiting for A to consume its documents before execution can continue. It seems that the maxTimeMS option is not handled properly when that happens; the cursor will hang indefinitely rather than returning when maxTimeMS is reached. 

      charlie.swanson@mongodb.com suggested using something like this to wait on condition variables so the maxTimeMS can be respected, rather than hanging on the mutex as happens now.

            Assignee:
            martin.neupauer@mongodb.com Martin Neupauer
            Reporter:
            will.buerger@mongodb.com Will Buerger
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: