[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:
Backports
Related
related to SERVER-53150 Specify input/output to isMaster/hell... Closed
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:
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 "SERVER-53150: Specify input/output to hello command"

This reverts commit 26ecc0880280ada1b9f77b3f07544843e50e3088.
Branch: master
https://github.com/mongodb/mongo/commit/4fc5efba5a232906fa0d9702e3b650bdf353a382

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 DOCS-14203 to offer this tip to users in the currentOp documentation. I think it makes sense to hold off on considering this a stable field as we may find it is not sufficient to remove user confusion over currentOp output. I definitely welcome comments/suggestions on DOCS-14203.

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 SERVER-53150 we have marked the "awaitable" field as "unstable", meaning it isn't in API Version 1: we don't expect to document it, nor promise that applications can rely on it without experiencing any incompatible changes in the future.

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
Branch: master
https://github.com/mongodb/mongo/commit/26ecc0880280ada1b9f77b3f07544843e50e3088

Comment by Tyler Seip (Inactive) [ 01/Feb/21 ]

Some evidence that the change is working:

mongos> db.currentOp()
...
                {
                        "shard" : "__unknown_name__-rs0",
                        "type" : "op",
                        "host" : "ip-10-122-4-220:20000",
                        "desc" : "conn5",
                        "connectionId" : 5,
                        "client_s" : "10.122.4.220:59562",
                        "clientMetadata" : {
                                "driver" : {
                                        "name" : "NetworkInterfaceTL",
                                        "version" : "4.9.0-alpha4-63-gbda3d84"
                                },
                                "os" : {
                                        "type" : "Linux",
                                        "name" : "Ubuntu",
                                        "architecture" : "x86_64",
                                        "version" : "18.04"
                                }
                        },
                        "active" : true,
                        "currentOpTime" : "2021-02-01T17:06:09.501+00:00",
                        "threaded" : true,
                        "opid" : "__unknown_name__-rs0:1803",
                        "secs_running" : NumberLong(5),
                        "microsecs_running" : NumberLong(5409334),
                        "op" : "command",
                        "ns" : "admin.$cmd",
                        "command" : {
                                "isMaster" : 1,
                                "awaitable" : 1,
                                "maxAwaitTimeMS" : NumberLong(10000),
                                "topologyVersion" : {
                                        "processId" : ObjectId("6018349255641bc9ace59712"),
                                        "counter" : NumberLong(8)
                                },
                                "internalClient" : {
                                        "minWireVersion" : 12,
                                        "maxWireVersion" : 12
                                },
                                "maxTimeMSOpOnly" : NumberLong(20000),
                                "$db" : "admin"
                        },
                        "numYields" : 0,
                        "waitingForLatch" : {
                                "timestamp" : ISODate("2021-02-01T17:06:04.192Z"),
                                "captureName" : "FutureResolution"
                        },
                        "locks" : {
 
 
                        },
                        "waitingForLock" : false,
                        "lockStats" : {
 
 
                        },
                        "waitingForFlowControl" : false,
                        "flowControlStats" : {
 
 
                        }
                }, 

 

Generated at Thu Feb 08 05:25:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.