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

Consider making waitAfterPinningCursorBeforeGetMoreBatch only hang instead of also fiddling with locks (while-loop taking and releasing locks)

XMLWordPrintableJSON

    • Type: Icon: Task Task
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Query Execution

      I think the looping of taking and releasing locks is outdated now that MMAP is gone. The failpoint name suggests it is only used to hang an active getMore command. The failpoint and lock manipulation were added in SERVER-21997 because of a MMAP deadlock: MMAP is gone now. The looping today is occurring via this lambda passed into CurOpFailpointHelpers::waitWhileFailPointEnabled

      My goal in filing this ticket is to get rid of the UninterruptibleLockGuard used here for a failpoint. UninterruptibleLockGuard should be used when there is no alternative: it's a hack that breaks rules and we'd like to remove it entirely. I didn't figure out why SERVER-27534 added the use to the failpoint case.

      If the loop cannot be removed, I wonder if the UninterruptibleLockGuard use can be.

            Assignee:
            backlog-query-execution [DO NOT USE] Backlog - Query Execution
            Reporter:
            dianna.hohensee@mongodb.com Dianna Hohensee (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: