-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
logger: macros evaluate logging level before invoking logger #2751
Changes from 5 commits
76b4d13
27a9b7f
ef37d67
3191354
4641d74
852538a
8e15dd3
e4dc3af
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -37,4 +37,48 @@ TEST(Logger, All) { | |
// Misc logging with no facility. | ||
ENVOY_LOG_MISC(info, "fake message"); | ||
} | ||
|
||
TEST(Logger, evaluateParams) { | ||
uint32_t i = 1; | ||
|
||
// set logger's level to low level. | ||
// log message with higher severity and make sure that params were evaluated. | ||
GET_MISC_LOGGER().set_level(spdlog::level::info); | ||
ENVOY_LOG_MISC(warn, "test message '{}'", i++); | ||
ASSERT_THAT(i, testing::Eq(2)); | ||
} | ||
|
||
TEST(Logger, doNotEvaluateParams) { | ||
uint32_t i = 1; | ||
|
||
// set logger's logging level high and log a message with lower severity | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Super nitty, mind set ->Set here and above and do -> Do on 69? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for catching it. It has been corrected. |
||
// params should not be evaluated. | ||
GET_MISC_LOGGER().set_level(spdlog::level::critical); | ||
ENVOY_LOG_MISC(error, "test message '{}'", i++); | ||
ASSERT_THAT(i, testing::Eq(1)); | ||
} | ||
|
||
TEST(Logger, logAsStatement) { | ||
// Just log as part of if ... statement | ||
|
||
if (true) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: same here as below, can we just add simple counter behavior above to ensure that this test not only compiles, but that it acts as expected? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done. |
||
ENVOY_LOG_MISC(critical, "test message 1"); | ||
else | ||
ENVOY_LOG_MISC(critical, "test message 2"); | ||
|
||
// do the same with curly brackets | ||
if (true) { | ||
ENVOY_LOG_MISC(critical, "test message 3"); | ||
} else { | ||
ENVOY_LOG_MISC(critical, "test message 4"); | ||
} | ||
} | ||
|
||
#ifdef NVLOG | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does the CI ever run in a mode with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. CI probably never runs with NVLOG defined. I invoked the test manually by running There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we set one of the circleCI jobs to define NVLOG? Maybe the "release" job? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That is probably good idea. I was surprised when my first PR #2676 was reverted even though it passed CI checks. If "release" CI job tests release image, it should probably use "release" compile flags. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Tracking here: #2754 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ggreenway I don't think we should do it on the release job because that job is used for building the docker images. Not to throw a wrench in this, but I'm wondering with all the macros we have now and this change, if we should just kill NVLOG entirely. There is some perf benefit but now that the logs don't evaluate it's probably small. I think all that would be needed is to add some type of macro/guard for the few places where we use NVLOG to block an expensive iteration. Thoughts? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Performance overhead is one function call and comparison between integers. Not much. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think at this point I would vote to just kill NVLOG and replace with some additional macros for the places in which we use it for larger guards, but no objection to merging this PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @cpakulski are you interested in just getting rid of NVLOG as part of this PR? |
||
TEST(Logger, doNotExpandTraceAndDebug) { | ||
// The following two macros should not be expanded to no-op if NVLOG compile flag is defined. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: I realize that this is just a test to ensure they compile, but do we also want to add the incrementing counter behavior used above just to ensure the statements act as stated? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done. Thanks for review and suggestions. |
||
ENVOY_LOG_TO_LOGGER(nonExistingLogger, trace, "test message 5"); | ||
ENVOY_LOG_TO_LOGGER(nonExistingLogger, debug, "test message 6"); | ||
} | ||
#endif /* NVLOG */ | ||
} // namespace Envoy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: prefer
EXPECT*
for non-fatal failures, sinceASSERT*
will essentially abort the test case. Here and elsewhere.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion. Done.