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

NetworkInterfaceASIO _asyncRunCommand should not use _request field

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.6.0-rc2
    • Component/s: Networking
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Platforms 2017-05-08, Platforms 2017-05-29, Platforms 2017-09-11, Platforms 2017-10-02, Platforms 2017-10-23, Platforms 2017-11-13
    • Linked BF Score:
      19

      Description

      The `_request` field on an AsyncOp represents an overarching user request being run through NetworkInterfaceASIO. We may call _asyncRunCommand many times within that one user request. The underlying _request field should not change for each "mini request" run through _asyncRunCommand. By accessing this field within that method we will log incorrect/misleading things about what command we are running.

      For example, when we refresh connections, we re-use part of the NetworkInterfaceASIO state machine. When we are refreshing connections, we do not set the _request field, which leads to confusing log messages with default information:

      "Failed to heartbeat to :27017 - HostUnreachable: An established connection was aborted by the software in your host machine."
      

      Note that this log line is from a cluster that did not have a member running on localhost:27017, and had never before connected to a host at :27017.

      This extends to any code that we might flow through from _asyncRunCommand before returning from running the command, such as _validateAndRun and associated paths.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: