[SERVER-37247] Rarely macro should log first use of deprecated command Created: 21/Sep/18  Updated: 08/Jan/24  Resolved: 16/Nov/18

Status: Closed
Project: Core Server
Component/s: Logging
Affects Version/s: None
Fix Version/s: 4.1.6

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

Issue Links:
Related
related to SERVER-5739 Race condition in SOMETIMES/MONGO_SOM... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Dev Tools 2018-10-22, Dev Tools 2018-11-05, Dev Tools 2018-11-19
Participants:

 Description   

Many people use the rarely and occasionally macros for logging or warning the end user without completely filling the logs with these warnings.

Today, the rarely marco skips the first use and logs on the 128th use.



 Comments   
Comment by Githook User [ 16/Nov/18 ]

Author:

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

Message: SERVER-5739 Fix races in RARELY/OCCASIONALLY.

Switch to using C++ instead of macros.
Fix SERVER-37247: these should fire on first hit.
Branch: master
https://github.com/mongodb/mongo/commit/63e43f1bb47f7bddf3dc37ad03a2bbee6d2a9423

Comment by Billy Donahue [ 06/Nov/18 ]

Would be fixed incidentally by https://mongodbcr.appspot.com/239630001/,
which primarily targets SERVER-5739 (to use an atomic counter and get away from using macros).

Comment by Andrew Morrow (Inactive) [ 21/Sep/18 ]

Also, I suspect simply moving to post-increment would address the issue in this ticket.

Comment by Andrew Morrow (Inactive) [ 21/Sep/18 ]

mira.carey@mongodb.com - We actually did the work to make them atomic, but we decided to hold off on committing it, see comment history on SERVER-5739.

Comment by Mira Carey [ 21/Sep/18 ]

To expand. It seems like we mostly/often use RARELY and OCCASIONALLY for logging. Seems like it'd be a quality of life improvement to see these on the first invocation, instead of the nth.

In this case, I think we have an instance where we're using the wrong method for rate-limiting logging, instead of having the wrong implementation of a macro. The current set of macros use non-atomics in multi-threaded contexts. Because of that, having a RARELY or an OCCASIONALLY fire at all is a bit of a dicey thing. If we actually want to be sure that we're going to act on these branches, we'd need versions that used atomics.

A good solution to this ticket should separate out the callers we want to run "sometime, maybe, hopefully, with some ub" from the ones where we want "do the thing every N passes".

Logging per deprecated command invocation is clearly in the latter category. I'm a little less sure of the other call sites

Generated at Thu Feb 08 04:45:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.