-
Type: Task
-
Resolution: Gone away
-
Priority: Major - P3
-
Affects Version/s: None
-
Labels:None
Description
This adds a new optional parameter 'waitForLock' to the 'collStats' command. The parameter defaults to 'true'. When set to true (or by default), the behavior is unchanged from the existing behavior of 'collStats' blocking behind its lock acquisition to collect statistics. When set to false, 'collStats' will not block behind its lock acquisition. Instead, if the lock cannot be immediately acquired, the 'collStats' command will still succeed but its response will not include any statistics. This new waitForLock=false mode is used by FTDC.
Description of Linked Ticket
Currently FTDC takes out locks in two places (once when running WiredTiger and once when running with replication).
WiredTiger: https://github.com/mongodb/mongo/blob/1dc2afc8b5ce09d88535049df2ad72adc0434cc8/src/mongo/db/storage/wiredtiger/wiredtiger_server_status.cpp#L60
Replication: https://github.com/mongodb/mongo/blob/c1e7921e9d69bd9a37761deb58d119a324341a54/src/mongo/db/ftdc/ftdc_mongod.cpp#L47-L60 which calls into https://github.com/mongodb/mongo/blob/1dc2afc8b5ce09d88535049df2ad72adc0434cc8/src/mongo/db/stats/storage_stats.cpp#L57
Both can wait forever which can be undesirable for FDTC. Instead it may be useful to utilize "tryLocks" such that an FTDC round can make progress and output data despite some pieces blocking.
However such a change would also affect serverStatus output thus be an API change that can affect downstream callers.
Scope of changes
Impact to Other Docs
MVP (Work and Date)
Resources (Scope or Design Docs, Invision, etc.)
- documents
-
SERVER-30888 Have FTDC code paths obtain locks with a timeout.
- Closed