[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 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". |