[SERVER-51358] Clearly indicate "awaitable" operations in currentOp Created: 05/Oct/20 Updated: 10/May/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.4.1 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eric Sedor | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | sa-remove-fv-backlog-22 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Service Arch
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v5.0
|
||||||||||||
| Sprint: | Service arch 2020-12-28, Service Arch 2021-02-08, Service Arch 2021-06-14, Service Arch 2021-06-28, Service Arch 2021-07-12 | ||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Story Points: | 5 | ||||||||||||
| Description |
|
Awaitable isMaster commands can add noise to currentOp. While it's currently possible to filter them out using filters like {command.isMaster:{$exists:false}}, {command.maxAwaitTimeMS: {$exists:false}}, {command.maxAwaitTimeMS: "$ne":10000}} and/or {"ns":{"$ne":"admin.$cmd"}, it would be nice to have an explicit field to filter on, such as "awaitable":true. Or even, if possible, awaiting: true to indicate the operation is both awaitable AND that the clock is ticking on its awaitTimeMS. This may also be of use for Change Stream and oplog tailing operations which are (I believe) the only other places currently using this sort of mechanism. Ideally, given the prevalence of these awaitable isMaster commands in 4.4+, an explicit filter would not be required to hide them. |
| Comments |
| Comment by Githook User [ 25/Feb/21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Tyler Seip', 'email': 'Tyler.Seip@mongodb.com', 'username': 'tseip-mongo'}Message: SERVER-51358: Revert "SERVER-51358: Indicate awaitable operations explicitly" and a small part of " This reverts commit 26ecc0880280ada1b9f77b3f07544843e50e3088. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Eric Sedor [ 08/Feb/21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Thanks for pulling me back in here jesse, matthew.saltz, I think we should revert this and regroup, as there must have been a miscommunication. We should have a solution that works for replica sets with no driver changes. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by A. Jesse Jiryu Davis [ 08/Feb/21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I don't know if this ticket was the best way to accomplish your goal. Perhaps it would be better to mark awaitable isMaster with a special field in currentOp without relying on the client to pass a new parameter. Both mongod and mongos know whether a given operation is an awaitable ismaster already; they could add this field in currentOp themselves, and then this technique would work with replica sets as well as sharded clusters. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Eric Sedor [ 08/Feb/21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I've opened | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Matthew Saltz (Inactive) [ 08/Feb/21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
jesse We added it to the ServerDiscoveryMonitor so it should be present in sharded clusters but not single replica set clusters (since as you said, drivers aren't passing this field). eric.sedor Is that sufficient? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by A. Jesse Jiryu Davis [ 08/Feb/21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Meanwhile, as part of | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by A. Jesse Jiryu Davis [ 07/Feb/21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I'm curious about this (since I wrote some of the "awaitable isMaster" designs) - does any client currently pass "awaitable" or not? If not, does the code change for this ticket accomplish the goal? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 01/Feb/21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Tyler Seip', 'email': 'Tyler.Seip@mongodb.com', 'username': 'tseip-mongo'}Message: SERVER-51358: Indicate awaitable operations explicitly | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tyler Seip (Inactive) [ 01/Feb/21 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Some evidence that the change is working:
|