DRIVERS-2578 Drivers use polling SDAM on AWS Lambda

[ShaneHarvey]

DRIVERS-2578

Changes:

• Disable streaming SDAM by default on AWS Lambda and similar FaaS platforms.
• Introduce the serverMonitoringMode=stream/poll/auto URI option.
• Add Unified Test Format version 1.17 to add support for server heartbeat events and asserting on the "awaited" field.
• Clients MUST NOT use dedicated connections to measure RTT when using the polling protocol.

Checklist:

• Update changelog.
• Make sure there are generated JSON files from the YAML test files.
• Test changes in at least one language driver. Python implementation: PYTHON-3668 Use polling SDAM mode on FaaS and add sdamMode=auto/stream/poll mongo-python-driver#1360
• Test these changes against all server versions and topologies (including standalone, replica set, sharded clusters, and serverless).

[prestonvasquez]

Do you think it's worth extending the test plan for handshakes (https://github.com/mongodb/specifications/blob/master/source/mongodb-handshake/handshake.rst#test-plan) to check that the the initial handshake uses OP_QUERY? As of this ticket, there is a possibility that polling could be used with a server versions >= 4.4 . And AFAIK this is novel and so potentially important to ensure that correct handshake logic is being implemented.

It's probably not very important, as the wire message between streaming / polling are not that different. But I do notice we don't check this anywhere and so it could be useful to do so as a part of this change.

Here is an example of how the Go Driver intends to check this: https://github.com/mongodb/mongo-go-driver/blob/fe237bb0079574fb76c859332218d7c49921210d/mongo/integration/handshake_test.go#L177-L182

CC: @baileympearson

[ShaneHarvey]

I think this idea is worthwhile but as a new drivers ticket since this PR doesn't change the OP_QUERY vs OP_MSG behavior.

[matthewdale]

Is there a reason we want to disable the RTT monitor for servers that don't support streaming heartbeat (i.e. server versions before 4.4)?

From reading the rationale "Why disable the streaming protocol on FaaS platforms like AWS Lambda?", it sounds like the goal of not starting the RTT monitor is to reduce open connections for FaaS environments. However, the suggested change would disable the RTT monitor for all databases earlier than 4.4, not just FaaS environments.

[baileympearson]

This isn't a new requirement - drivers shouldn't be creating RTT monitors when the polling protocol is used. The rtt monitors are only necessary when using the awaitable hello protocol, because then a round trip to the server can take up to maxAwaitTimeMS. https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-monitoring.rst#measuring-rtt

[matthewdale]

The spec wording and pseudo-code don't match your assertion.

The Measuring RTT section specifically says drivers can still use a separate RTT monitor for any server version:

For consistency, clients MAY use dedicated connections to measure RTT for all servers, even those that do not support awaitable hello or legacy hello.

The current pseudo-code from the Monitor thread section also describes always starting the RTT monitor, independent of server version:

class Monitor(Thread):
...

  def run():
      # Start the RttMonitor.
      rttMonitor.run()
...

The new spec wording in this PR only suggests disabling the RTT monitor when streaming is disabled, but nothing about whether or not it's supported:

When the streaming protocol is disabled the client MUST use the polling protocol and MUST NOT start an extra thread or connection for Measuring RTT.

Disabling the RTT monitor when streaming isn't supported is allowed by the spec. However, putting it in the pseudo-code makes it seem like a new requirement that conflicts with the spec wording.

[prestonvasquez]

@ShaneHarvey Can you opine on this?

[ShaneHarvey]

Yes this PR changes the rules to disallow using an extra thread/socket for RTT on <4.4 servers. The rationale is that the extra connection limits scaling and puts unnecessary load on the server, especially in Lambda where MongoClients are not shared. Although the motivation is mostly Lambda this is still a beneficial change for all environments.

[prestonvasquez]

To @matthewdale 's point, should this section from Measuring RTT be removed or updated to reflect these rule changes? :

For consistency, clients MAY use dedicated connections to measure RTT for all servers, even those that do not support awaitable hello or legacy hello.

[ShaneHarvey]

Good point. I updated this section to say clients MUST NOT use dedicated connections to measure RTT in this case.

[matthewdale]

Thanks for the clarification. Does that imply that the polling monitor should measure RTT (e.g. to support CSOT)? For the Go driver, that would significantly increases the scope of this change because we'd have to build RTT monitoring capability into the polling monitor.

[ShaneHarvey]

I'm confused by this question because the polling protocol always included RTT monitoring. But yes, the polling protocol should measure RTT via it's own heartbeats, not with a separate dedication connection.

[matthewdale]

Looking closer, the actual change in the Go driver would probably be minimal. It does add complexity because there is no longer a single source of RTT data for CSOT, but the change only impacts a few lines of code. Consider this comment thread resolved.

[ShaneHarvey]

I've updated the Unified Test Format to version 1.17 by adding support for listening to SDAM ServerHeartbeat events and asserting on the "awaited" field. This improves the SDAM integration test. Ready for another look.

[matthewdale]

Looks good 👍