-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Rebind log4j2 metrics if configuration is changed #5810
Open
pativa
wants to merge
4
commits into
micrometer-metrics:main
Choose a base branch
from
pativa:log4j2-reconfigure-rebind
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I'm curious about the choice of
changeListeners
being aList
. Would it be better to use aConcurrentMap
keyed on theMeterRegistry
passed tobindTo
like theMetricsFilter
map? In most expected usage, it won't matter either way, but maybe it's safer and more consistent to have only one listener per registry unless I'm missing some reason that may not be what we want.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.
Ok, so this will be kind of a weird case, but using a
ConcurrentMap
the following test (where we bind theLog42Metrics
instance to the sameMeterRegistry
multiple times) would fail. I don't know what the best behavior when binding to the same registry twice would be, but currently it will count the logs twice (which might be what could be said to be expected?)If we use a
the following may not be enough to clean the
loggerContext
anymore:As the same changeListener may have been registered multiple times, and only one would be removed by log4j2.
Using the current setup with a
List
does not fail the test.Other solutions to the above would be to not allow binding the filter to the same registry twice (e.g. throwing exception?) or not counting twice when binding again (e.g. ignore the second call to
bindTo()
with the sameMeterRegistry
).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.
While we don't document it anywhere as far as I know, binding multiple times to the same registry I think we should generally classify the behavior as unspecified, meaning no guarantee what the outcome will be for any given binder implementation. I'm not sure why someone would intentionally bind multiple times to the same registry, and I think we can wait to hear from a user before we go to the effort of trying to support that. Thus I think doing nothing in particular would be an option here, but if we want to be extra cautious we can decide what the behavior should be in this case. I would go with ignoring the second call to
bindTo
with the same registry and logging a warning if we want to handle this case at all. Pinging @jonatan-ivanov to see what he thinks on this.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.
Yeah, I would be fine with any handling for the case that
bindTo
is called twice, it's just important that the cleanup works regardless.Ignoring the second call / logging a warning would work fine, as long as we don't register the
PropertyChangeListener
twice (as the second listener also has to be removed).