Skip to content
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

reduces log level for some chatty logs #5082

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

keith-turner
Copy link
Contributor

No description provided.

@keith-turner keith-turner added this to the 4.0.0 milestone Nov 19, 2024
@@ -106,7 +106,8 @@ public static void validate(AccumuloConfiguration config, Level level)

Set<String> defaultService = Set.of(DEFAULT_COMPACTION_SERVICE_NAME);
if (servicesConfig.getPlanners().keySet().equals(defaultService)) {
log.warn("Only the default compaction service was created - {}", defaultService);
log.atLevel(level).log("Only the default compaction service was created - {}",
Copy link
Contributor

@ddanielr ddanielr Nov 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Iirc, the original goal of this log message was to alert users that the compaction service might not have been properly created. However, if a custom service was never defined than this just logs endlessly.

Might be a good follow on to try and validate the servicesConfig planners vs what planner prefixes might be set in the properties? and only log if there's a difference?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have implementions for a ConditionalLogger. One deduplicates and the other escalates. If you only want to see the message once every N time units, then use the DeduplicatingLogger. If you want to see the message at level X once every N time units, and at level Y the remaining times, then use the EscalatingLogger.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be a good follow on to try and validate the servicesConfig planners vs what planner prefixes might be set in the properties? and only log if there's a difference?

Could this be accomplished by adding unit test for CompactionServicesConfig that verifies it fails/throws an exception under these conditions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants