-
Notifications
You must be signed in to change notification settings - Fork 5.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
Use a deep copy of query stats whose values won't change during sorting. #597
base: main
Are you sure you want to change the base?
Use a deep copy of query stats whose values won't change during sorting. #597
Conversation
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.
Another unrelated thing, it might be better to unify the coding style?
eg:
for() {
// code
}
not:
for()
// code
not
// took our snapshot. If the timestamps disagree, it means | ||
// that this item is no longer the oldest (and it likely now | ||
// one of the newest). | ||
if(mqs.lastInvocation == mqs.queryStats.lastInvocation) { |
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.
What happens, when all (or enough) of the stats have been changed in between? Wouldn't we get a IndexOutOfBoundException? May be, we should add a guard to the while expression and log a message, that we could net free enough stats.
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 question. If 100% of the stats have been updated, then we will remove nothing, no space will be gained, and we will end up running off the end of the list, throwing an error.
I see a few options:
- YOLO! Just let the loop run and hope for the best! j/k
- Ensure
removeIndex
doesn't grow too high, then just stop - Do (2), and repeat the sort+loop until we remove enough entries to meet cache-size expectations
I think probably (2) is sufficient. Thoughts?
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 had number two in mind, with a warn message at the end, when we could not free enough stats.
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.
Maybe use PriorityQueue
instead of ArrayList
is a better way? The latter will not have the problem of removeIndex
being too high. See below:
protected void removeOldest(ConcurrentHashMap<String,QueryStats> queries) {
int removeCount = queries.size() - maxQueries;
if (removeCount <= 0) {
return;
}
// Make a defensive deep-copy of the query stats list to prevent
// concurrent changes to the lastModified member during list-sort
PriorityQueue<MiniQueryStats> queue = new PriorityQueue<>(queries.size(), miniQueryStatsComparator);
for(QueryStats stats : queries.values()) {
queue.offer(new MiniQueryStats(stats));
}
while (removeCount > 0 && !queue.isEmpty()) {
MiniQueryStats mqs = queue.poll();
// Check to see if the lastInvocation has been updated since we
// took our snapshot. If the timestamps disagree, it means
// that this item is no longer the oldest (and it likely now
// one of the newest).
if(mqs.lastInvocation == mqs.queryStats.lastInvocation) {
String sql = mqs.queryStats.query;
queries.remove(sql);
removeCount--;
if (log.isDebugEnabled()) log.debug("Removing slow query, capacity reached:"+sql);
}
}
}
Fixes https://bz.apache.org/bugzilla/show_bug.cgi?id=58489