[SERVER-50630] ProgramOutputMultiplexer's log buffer grows without bound Created: 28/Aug/20  Updated: 19/Jun/23  Resolved: 19/Jun/23

Status: Closed
Project: Core Server
Component/s: Shell
Affects Version/s: 4.5.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Ian Boros Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Do Votes: 0
Labels: sdp-backlog-purge
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Server Development Platform
Operating System: ALL
Participants:
Linked BF Score: 0
Story Points: 2

 Description   

The ProgramOutputMultiplexer includes a buffer which stores all of the logs from all of the mongo shell's child processes. The buffer is not cleared until the mongo shell exits.

In tests which produce large amounts of log output (for example, tests which run with a higher log verbosity) this can cause the shell to crash while attempting to grow the buffer to an unreasonable size.

We should consider changing the ProgramOutputMultiplexer to only store the output from the child processes in an "opt-in" fashion, rather than by default. As far as I know, the number of tests which rely on re-reading log output is relatively small.



 Comments   
Comment by Alex Neben [ 19/Jun/23 ]

This has been identified as work that the SDP team won't do in the near term. Please reopen with a comment if you feel this work should be reprioritized and explain why.

Comment by Steven Vannelli [ 10/May/22 ]

Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions.

Comment by Brooke Miller [ 10/Sep/20 ]

In triaging, we discussed that upon this change, we need to send an email to server engineers letting them know that they need to explicitly opt-in so that they don't experience issues. Also, we should audit the existing 100+ tests that check log output, so we will need to modify them.

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