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

Correct interruptibility in MultiIndexBlock destructor

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.7.9
    • Fix Version/s: 4.0.0-rc1, 4.1.1
    • Component/s: Storage
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0
    • Sprint:
      Storage NYC 2018-06-04
    • Linked BF Score:
      64

      Description

      The MultiIndexBlock destructor should correctly instantiate an UninterruptibleLockGuard by assigning it to a variable name that stays in scope.

      Original text:
      Both renameCollection and compact commands use a MultiIndexBlock to rebuild indexes, which is not resilient to lock interrupts, but handles interruptibility through periodic calls to checkforInterrupt().

      An UninterruptibleLockGuard should be used in both commands, similar to what is already done for the createIndexes command.

      the jstestfuzz_interrupt_replication test suite has found that interrupting these commands can result in an fassert when cleaning up partially built indexes. For unknown reasons, the existing UninterruptibleLockGuard in the destructor does protect against this failure, and can just be removed.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              louis.williams Louis Williams
              Reporter:
              louis.williams Louis Williams
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: