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

Fix early-exits triggered when user specifies TCP Fast Open server parameters

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.1.0-rc0, 7.0.5, 6.0.13
    • Affects Version/s: None
    • Component/s: None
    • None
    • Service Arch
    • Fully Compatible
    • ALL
    • v7.0, v6.0
    • Service Arch 2022-12-26, Service Arch 2022-11-28, Service Arch 2022-12-12, Service Arch 2023-01-09, Service Arch 2023-01-23, Service Arch 2023-02-06, Service Arch 2023-06-12, Service Arch 2023-06-26, Service Arch 2023-07-10, Service Arch 2023-07-24, Service Arch 2023-08-07

      Background/Problem

      As part of implementing TCP Fast Open support, we calculate a variable that indicates whether the user specified any TCP Fast Open server parameters.

      We use this variable in some places to decide whether to emit logs about success/failure enabling TCP Fast Open. We also intend to use this to decide whether to fail from connection establishment.

      However, we forget to check whether the given error code indicates success or failure – the consequence is that whenever a user specifies any TCP Fast Open parameter, whether to turn it on, turn it off, or change the queue size, we will always fail connection establishment.

      In some cases, this can trigger a crash, as seen in the linked HELP ticket. In other cases, this just permanently stalls the server, because we never establish the listener thread that would accept connections.

      Relatedly, we always enable TCP Fast Open, even if the user attempts to disable it via server parameter.

      Solution

      • Only return early from connection establishment if the error code is a failure.
      • Add logic only to enable TCP Fast Open if either the user doesn't specify (implicit enablement) or if the user specifies to enable TCP Fast Open. Do not enable it if the user indicates not to enable TCP Fast Open.
      • Add tests to ensure that the behavior has been fixed.

            Assignee:
            billy.donahue@mongodb.com Billy Donahue
            Reporter:
            blake.oler@mongodb.com Blake Oler
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: