-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: 7.6.0
-
Component/s: SDAM
-
(copied to CRM)
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Use Case
Expected Behavior
After a mongos restart, the latency measurement on a server connection should be updated at regular intervals as it was before the restart.
Actual Behavior and Impact
During a rolling mongos restart, a server node enters quiesce mode and answers the RTT pinger's hello with ShutdownInProgress.
RTTPinger.measureRoundTripTime's onrejected callback destroys the connection, sets it to undefined, and returns without setting another measureAndReschedule (which is what calls measureRoundTripTime).
latestRtt retains its last measurement, and if that measurement is low enough, it becomes the winning low latency server to connect to according to latencyWindowReducer (server_selection.ts), even if it is not the lowest latency server anymore.
This likely implicitly impacts many users. The current workaround is to restart the application, which flushes the stuck latestRtt value.
Dependencies
- none
Risks/Unknowns
- What could go wrong while implementing this change?
- n/a
- Is there an opportunity for better cross-driver alignment or testing in this area?
- The spec already covers this scenario, the Node driver is misaligned: https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-monitoring.md#rtt-thread
- Is there an opportunity to improve existing documentation on this subject?
- n/a
Acceptance Criteria
Implementation Requirements
- RTTPinger moves its scheduling mechanism to a place outside of a success/fail block so that it runs unconditionally until the connection is closed explicitly.
Testing Requirements
- there is an opportunity for an integration test to replicate this scenario, and possibly a unit test with mocks
- The spec prose test gets close to this scenario, but doesn't cover it 100% https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/tests/README.md#rtt-tests - we should see if we have this test (a cursory glance says no but I have learned that depending on the age of the area of the driver it may either not exist or exist under a different name)