-
Type: Improvement
-
Resolution: Unresolved
-
Priority: 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, Networking & Obs 2024-10-14, Networking & Obs 2024-10-28, Networking & Obs 2024-11-11
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.
- related to
-
SERVER-93568 Replace enterprise-rhel8-sdam-replica-set-monitor-64-bit build variant with config fuzzer
- Needs Scheduling