Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-75277

TTL deleter attributes resource metrics across multiple databases

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Critical - P2 Critical - P2
    • 7.0.0-rc0, 6.3.1
    • Affects Version/s: 6.2.1
    • Component/s: None
    • Labels:
      None
    • Storage Execution
    • Fully Compatible
    • ALL
    • v6.3
    • Hide

      You can see the issue if you add one invariant to ScopedMetricsCollector constructor, like this:

      ...
    invariant(!metrics.hasCollectedMetrics());   // <- add this new line!
    metrics.beginScopedCollecting(opCtx, dbName);
}

      The TTL deleter will crash on that invariant if you have multiple collections with TTL indexes that it needs to pass over.

      Show
      You can see the issue if you add one invariant to ScopedMetricsCollector constructor, like this: ... invariant(!metrics.hasCollectedMetrics()); // <- add this new line! metrics.beginScopedCollecting(opCtx, dbName); } The TTL deleter will crash on that invariant if you have multiple collections with TTL indexes that it needs to pass over.
    • Execution Team 2023-04-03
    • 0

      The ResourceConsumption::ScopedMetricsCollector constructor tells the MetricsCollector attached to the current OperationContext to begin recording metrics. The ScopedMetricsCollector destructor then tells the MetricsCollector to stop recording metrics and merges the MetricsCollector's metrics into the global map, keyed on database name.
      This normally works fine, except that it doesn't clear the MetricsCollector after merging the metrics. The code assumes the MetricsCollector will destruct after this point.
      This means if you happen to encounter another ScopedMetricsCollector before the OperationContext/MetricsCollector destructs, it records more metrics on top of the ones it already collected, and then merges those erroneous stats into a possibly different database in the global metrics map. See Steps to Reproduce.

            Assignee:
            louis.williams@mongodb.com Louis Williams
            Reporter:
            milkie@mongodb.com Eric Milkie
            Votes:
            1 Vote for this issue
            Watchers:
            21 Start watching this issue

              Created:
              Updated:
              Resolved: