[SERVER-40581] Separate OpDebug and AdditiveMetrics Created: 11/Apr/19 Updated: 06/Dec/22 Resolved: 22/Apr/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | currentOp, query | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query
|
| Participants: |
| Description |
|
The OpDebug member of CurOp prescribes a (completely unenforced) contract that only the owning thread may read/write it's data members. AdditiveMetrics, a member of OpDebug, stores counters to operations that can be aggregated across multiple operations within a single multi-statement transaction. There is currently no API compatible way to report AdditiveMetrics to the "currentOp" command, because it requires outside threads accessing OpDebug. My suggestion is to either pull AdditiveMetrics out of OpDebug or remove OpDebug entirely. AdditiveMetrics (or even CurOp) would then enforce concurrency control on member variables that may or may not be accessed by outside threads like the currentOp command. |
| Comments |
| Comment by Craig Homa [ 22/Apr/19 ] |
|
We're definitely interested in cleaning this up but expect this sort of cleanup to be packaged into future work on diagnostics. |