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

ensures instrumented cache is recording stats #4552

Merged
merged 1 commit into from May 21, 2024

Conversation

keith-turner
Copy link
Contributor

No description provided.

@keith-turner keith-turner added this to In progress in 3.1.0 via automation May 11, 2024
@keith-turner keith-turner added this to In progress in 2.1.3 via automation May 11, 2024
@keith-turner
Copy link
Contributor Author

keith-turner commented May 11, 2024

The motivation behind this is that in the past the scan servers tablet metadata cache was instrumented w/ micrometere but not recording stats. Was attempting to use the cache metrics and they were zero and/or non existent. Spent a long time tracking down why instrumentation was not working (was looking at micrometer source code first thinking there was a bug there). Finally realized it was a problem w/ how the cache was built, just happened to remember that recording stats is optional. So this change is an attempt to catch future changes where the cache is changed to no longer record stats. Tried to think of a more general way to catch this mismatch between cache builder and cahce insturmention that could catch the problem anywhere in the Accumulo code base, but could not think of anything. So this change adds a check to the place where I saw it and it caused me problems.

Copy link
Contributor

@cshannon cshannon left a comment

Choose a reason for hiding this comment

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

This seems ok to me, is there any risk with having the state check being added in a minor release of causing anything to break on upgrade that we would not want to happen?

@keith-turner
Copy link
Contributor Author

This seems ok to me, is there any risk with having the state check being added in a minor release of causing anything to break on upgrade that we would not want to happen?

I think the risk of this change is low because its one part of code checking another part of the code that is not configurable. So the user can not do anything ATM that would trigger this new check. It should only be triggered by a code change that disables recording stats when the cache is constructed.

@keith-turner keith-turner merged commit 4d3a4d5 into apache:2.1 May 21, 2024
8 checks passed
3.1.0 automation moved this from In progress to Done May 21, 2024
2.1.3 automation moved this from In progress to Done May 21, 2024
@keith-turner keith-turner deleted the ensure_recording branch May 21, 2024 16:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
2.1.3
Done
3.1.0
Done
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

2 participants