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

LogCaptureSink: ensure no incoming traffic after stop is requested

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 6.3.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Fully Compatible
    • ALL
    • Service Arch 2023-01-23
    • 0

      [Fix BF-26347]

      The boost::log API uses shared_ptr extensively.

      The call to stopCapturingLogMessages doesn't kill the sink, but it does remove it from the core, so it shouldn't be receiving new messages. But it will survive and continue delivering any log messages that it had already received but not yet delivered at the time it was detached, which is IIUC what's going on here.

      A couple of things that might work?

      • The stopCapturingLogMessages can be changed to wait for the sink to drain somehow.
      • The stopCapturingLogMessages call can quiesce the sink, so that its messages will no longer write to the vector.
      • Give boost full ownership of a proxy shared_ptr to sink. In stopCapturingLogMessages, call the core.detach_sink as usual, but we won't be pinning a reference to it anymore. When its destructor is called, we know boost is done with it and we can return.

      Draft fix: https://github.com/10gen/mongo/pull/9869

      Confirmation of this behavior from Andrey Semashev, boost::log's maintainer.
      https://stackoverflow.com/questions/64160749/can-we-verify-that-boostlog-core-did-remove-sink

            Assignee:
            billy.donahue@mongodb.com Billy Donahue
            Reporter:
            billy.donahue@mongodb.com Billy Donahue
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: