[SERVER-41040] isMaster flag to initiate long-polling Created: 07/May/19  Updated: 29/Oct/23  Resolved: 08/Nov/19

Status: Closed
Project: Core Server
Component/s: Networking
Affects Version/s: None
Fix Version/s: 4.3.1

Type: New Feature Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: A. Jesse Jiryu Davis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Service Arch 2019-05-20, Service Arch 2019-06-03, Repl 2019-08-12, Repl 2019-08-26, Repl 2019-09-09, Repl 2019-09-23, Repl 2019-10-07, Repl 2019-10-21, Repl 2019-11-04, Repl 2019-11-18
Participants:

 Description   

Add a flag, perhaps "maxTimeMS", to the isMaster command that initiates long-polling. The server will not respond until maxTimeMS expires or there is a server state change that might interest the client, such as a replica set member role change or a replica set config change.

Also add a field, perhaps "awaitedTimeMillis", to the reply, which is approximately the time the server waited between receiving the requested and assembling the reply. The client can subtract awaitedTimeMillis from the client's round trip latency measurement to estimate the network latency.



 Comments   
Comment by A. Jesse Jiryu Davis [ 08/Nov/19 ]

This ticket was a useful prototype, it will not be merged.

Comment by A. Jesse Jiryu Davis [ 10/May/19 ]

The drivers send a few arguments with MS (maxTimeMS, maxStalenessMS) and the server replies consistently with Millis, I propose we make all new field names Millis, both in requests and replies.

Comment by Andy Schwerin [ 10/May/19 ]

"millis" or "ms"? I can never remember what's consistent with other names
we use.

On Fri, May 10, 2019, 3:19 PM A. Jesse Jiryu Davis (Jira) <jira@mongodb.org>

Comment by A. Jesse Jiryu Davis [ 10/May/19 ]

I'm choosing the parameter name "awaitStatusChangeMillis" for now.

Comment by A. Jesse Jiryu Davis [ 10/May/19 ]

OK. I was noticing in fact that this is brittle. If CmdIsMaster::run() waits for maxTimeMS before unblocking, then if any code on its path back up to the network layer calls checkForInterrupt() it will throw. I'll use some other parameter name, suggestions welcome.

Comment by Andy Schwerin [ 10/May/19 ]

My memory on this is hazy, but I think the replication and query teams had some regrets about my decision to use maxTimeMS for that purpose on tailable cursor getMores.

Comment by A. Jesse Jiryu Davis [ 10/May/19 ]

OK, we do not want consistency with how "getMore" uses maxTimeMS?

Comment by Andy Schwerin [ 10/May/19 ]

I suggest not using maxTimeMS. Iirc, we have had problems in other long-poll scenarios conflating maxTimeMS with the concept of "return without error after this time period".

Generated at Thu Feb 08 04:56:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.