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

RSM can receive requests (that won't be failed) after drop()

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.3.1
    • Component/s: Internal Code
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Service Arch 2019-08-12, Service Arch 2019-08-26
    • Linked BF Score:
      39

      Description

      The RSM theoretically has a contract that all waiter-promises are fulfilled with an unsatisfied read preference error on drop(). It also supposes that after being removed from the RSM Manager that no new promises can be added.

      But there's a race that goes something like this:

      getHostOrRefreshCaller RSMM::shutdown()
      proceed to just before SetState::mutex acquisition, i.e. after check for isRemoved  
        swap monitors out and mark in shutdown + drop anchor
      acquire lock and emplace waiter  
        shutdown and join task executor

      This can lead to a situation where we add waiter to the rsm after a drop (and with no obvious path forward towards not needing to break that added promise)

      The fix is to:

      • change removal from the monitor manager into a drop() on the RSM
      • pivot from isRemovedFromManager to isDropped, and update isDropped under the setState mutex
      • check for isDropped instead of globalRSMonitorManager.isShutdown in notify

      This should ensure that removing a RSM from a manager is the same as dropping one and that drops serialize with calls to get (so that waiters can't race in during shutdown).

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: