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

Consider removing replicaSetMonitorProtocol parameter and associated protocol-specific build variants

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Networking & Observability
    • Networking & Obs 2024-08-19, Networking & Obs 2024-09-02, Networking & Obs 2024-09-16, Networking & Obs 2024-09-30

      We have a server parameter today replicaSetMonitorProtocol which can be set to either "sdam" or "streamable" to toggle whether internal clients should use either the traditional "polling" or newer "streaming" version of SDAM. And we have at least one separate build variant to test with the old protocol, for example enterprise-rhel8-sdam-replica-set-monitor-64-bit.

      The streaming protocol was introduced in 4.4, so at this point I don't think we end up in a situation where an internal client is talking to a mongod that doesn't support the streaming protocol. So I'm curious whether continuing to support, and test, polling SDAM in the server is necessary.

      Maybe we are relying on this for test coverage of how mongod works with non-streaming SDAM, which external clients could still be using? But that seems simple enough to test otherwise just via testing the hello command.

      I'm also not sure if we anticipate any possible need to start using polling in some case again and we want to keep the code in place and tested for that reason.

      Or maybe there are customers who are disabling streaming for some reason?

      I will mention that after 5 years of not giving users a choice, the drivers did recently decided to introduce a knob for this to continue letting users use polling, motivated by known issues with the streaming protocol in FaaS environments (DRIVERS-2246, DRIVERS-2578). So it might be safer to keep it, though I don't think the FaaS concerns with suspended hosts are relevant for internal clients.

            Assignee:
            patrick.freed@mongodb.com Patrick Freed
            Reporter:
            kaitlin.mahar@mongodb.com Kaitlin Mahar
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: