[SERVER-73026] LogCaptureSink: ensure no incoming traffic after stop is requested Created: 19/Jan/23  Updated: 29/Oct/23  Resolved: 20/Jan/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.3.0-rc0

Type: Bug Priority: Major - P3
Reporter: Billy Donahue Assignee: Billy Donahue
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Service Arch 2023-01-23
Participants:
Linked BF Score: 0

 Description   

[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



 Comments   
Comment by Githook User [ 20/Jan/23 ]

Author:

{'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}

Message: SERVER-73026 disable log sink before detaching it
Branch: master
https://github.com/mongodb/mongo/commit/042b97b3e3f1423bdcf66a6436ea4e236565e61b

Generated at Thu Feb 08 06:23:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.